“The request was too large” error until OpenSprinkler.sh restart

[qhvalley]

Rebuilding my Pi system (flamed triacs, new hardware needed). Built new Pi os – Debian 12/bookworm. Compiled OSPi – 2.4.0, firmware 2.2.0 (5). On system boot, cannot connect with the app, and web access reports “The request was too large”. If I restart OSPi with the shell script, all works as expected. journalctl shows nothing obvious to me.

Suggestions welcomed!

[Ray]

If you try to access:
https://demo.opensprinkler.com/
do you get the same error? The demo runs firmware 2.2.1(0) currently. The request too large error is usually due to the request header larger than the buffer size. This shouldn’t happen unless if you have a firewall or proxy that inserts additional data to the header.

[darren.macleod]

I have also run into the same issue.
Starting with a fresh install i can see the webpage on port 8080 but as soon as i reboot, i get “The request was too large” in the browser window.
I have no issues in seeing the website on the above demo.

[adepiero]

Same issue here. I opened an issue on the official GitHub page.

[Ray]

We are able to reproduce the issue so we are working on fixing it right now.

[Tony Stuck]

The request too large error is usually due to the request header larger than the buffer size. This shouldn’t happen unless if you have a firewall or proxy that inserts additional data to the header.

Yeah, for what it’s worth, I’ve run into this also, but it’s because I expose my OpenSprinkler web UI via Cloudflare Tunnels and put Cloudflare Access in front of it, so the world can’t see. CF Access drops a few authorization cookies (just shy of 1600 bytes) which get forwarded to the OpenSprinkler server, and it sounds like that’s too much for the buffer?

I ended up running an nginx proxy on the machine that runs my Cloudflare Tunnel to cut out the CF cookies before sending the requests to my OpenSprinkler controllers. If you’re increasing the buffer size to be able to handle this, that’d be convenient 🙂

[Ray]

We plan to address this in the next version of OTF library. Currently the incoming request is read into a 2K buffer, which is more than sufficient for most requests. Of course if Cloudflare adds a lot of extra header it can quickly exceeds the buffer size, we just didn’t know it could be a very large buffer.

[km9830]

I am now getting the same issue with cloudflare. Has the problem been fixed in the OTF library?

[Ray]

@km9830, please be more specific. How are you accessing the controller, what error messages are you getting. Are you able to go to:
https://demo.opensprinkler.com/
and see the interface there? There are several different scenarios discussed above, just saying ‘getting the same issue’ doesn’t give us enough details to help you diagnose.

[km9830]

1. I am trying to do a cloudflare zero trust tunnel to my open sprinkler.

2. I have successfully used the same cloudflare tunnel on two different applications: Home Assistant and Frigate. I am now trying to add OpenSprinkler.

3. When I try to connect up to the opensprinkler app using cloudflare, I think I can reach my opensprinker controller. But I get "The request was too large" on a single line. It looks as if the message is coming from my controller. See if screen capture works:

4. Without using cloudflare, I can connect up successfully with a browser using a local IP address 192.168.xx.xx to the controller, past the log in and use the controller successfully through the browser.

5. I can connect up to the https://demo.opensprinker.com successfully to the login screen.

Thanks so much for responding. Other things are working well.

[km9830]

@lostrockfarm. Would you be able to share me your nginx configuration that you described?

[dun4cheap]

I reported this behavior to Ray quite some time ago. I have an app I wrote in visual basic when the first hardware came out. It worked all along until the 2.221.

This hardware version 3 with newer version firmware above 2.19. My 2.3 and 2.2 hardware was not effected becuase Ray said that these were pretty much EOL. But recently their was a firmware 2.2.1 made available for the 2.3 hardware. So the 24 controller down below is 2.3 hardware with the new 2.2.1 firmware and it still works with my app. So hopefully this helps Ray troubleshoot the difference with the two controllers now on the same firmware. Ray let me know if you want me to try a test firmware or something. It would be nice to get this fixed since my app would backup and do mass updates with all 22 of my controllers at once. It would be nice is Samer would add these features to the APP. Mass backups of the settings of all my controlers. Display the hardware and Firmware and rain delays for the app. I have reached out to him a long time ago, but this just never was included.

Indx: 200 – HTTP/1.1 413 Request too large <— Hardware 3 AC with Firmware 2.2.1

24 Scanning For Controller: 192.168.3.24 <— Hardware 2.3AC with Firmware 2.2.1
Controller Found: 192.168.3.24

[Ray]

@dun4cheap, look, you need to provide some more specifics about your setup. Not everyone who gets this error has the same setup. Let me first clarify that this error is due to the OpenThingsCloud library that we use for enabling OTC remote access. The library handles both local and remote connections. The error occurs if it receives a header that’s larger than its allows size. Because OpenSprinkler hardware 2.x does not support OTC, this doesn’t apply to 2.x. So it’s only relevant to hardware v3.x.

As you can read from the above, some users encountered this because they are using CloudFlare Tunnels. I don’t have it so I can’t test it myself, but the bottom line is that it’s sending a request to the controller with an overly large header, causing the request too large error.

I don’t see any evidence you are using CloudFlare Tunnels. So if I had to take a guess, your Visual Basic script is probably sending a header that’s overly large. The first thing to try is to figure out what header it’s sending, and if it’s possible to reduce itself. Look, when you access the controller using a browser, you never encounter this issue because the browser doesn’t send a very large header. This error almost always happens when you use a script, or as said above, CloudFlare Tunnels, which possibly appends a large header.

We can certainly modify the OpenThingsCloud library to increase the allowed header size, but ESP8266 has limited memory size, so we can’t increase the limit arbitrarily. The question really is why your script is sending a very large header, and if it’s possible to shrink it.

Regarding the app: the app is just a front end / UI that we provide. Please note that you have access to the OpenSprinkelr API, you can write a custom front end / UI as you want, to provide backup features. The thing is no matter how we change the UI, it’s not going to fit everyone’s need. The whole point of making the project open-source is to give users the freedom to customize the firmware, the UI, in any way you want, instead of always relying on us to provide these custom features.

I also recommend you to use more modern scripting languages, like Python, Javascript, etc. I am not sure how many people still use Visual Basic. You are likely to get a lot more community support and sample code with Python and Javascript, than VB.

Finally, ChatGPT and other similar generative AI can easily write simple scripts in no time. Just describe what you want, the basic constraints, the variable names, it can produce the script / program you want instantly.

[Author]

Posts