Please see this post on the old forum where I broke down why this was happening and why it’s not really feasible to fix this as it’s tied to changes in Chrome, which serves as the backing browser stack for the WebViewer on most Android devices.
Edit: For discoverability purposes, here is the linked post in its entirety:
I poked around a bit and tried to mimic this as best I could given that I don’t have a ESP32 Cam. Here are the results of my analysis.
A python server running on port 8000 with a single file stream. The IP address of the machine had the same length as the one given in your pictures.
This means that the HTTP request line and the Host headers are exactly the same length as in your scenario.
I used Wireshark on the server to capture incoming packets to the python server. Here’s an example of the packet sent from my phone. It may differ slightly from your phone, but I think the point should generally be the same:
GET /stream HTTP/1.1
User-Agent: Mozilla/5.0 (Linux; Android 8.1.0; Pixel Build/OPM1.171019.012; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome 78.0.3904.96 Mobile Safari/537.36
Accept-Encoding: gzip, deflate
Based on what I’ve found about the ESP32 HTTP server processing of headers, the request line doesn’t count against the 512 bytes of headers, so we can start counting from the start of the Host field. The values, including the \r\n characters are as follows:
52 << this is the X-Requested-With header
which totals up to 498, 14 bytes shy of the 512 byte limit. If the host page has set cookies, then you’ll probably be above 512 and you’ll get the error. My guess is that your older version of Chrome that you downgrade to is not sending as many headers, and therefore gives you more flexibility in what works.
So how does this fit into compiled apps? As you can see on the X-Requested-With header we have the package name of the app. Your app’s package name will be appinventor.ai_<email address before @>.<project name>, which is likely bound to be longer than edu.mit.appinventor.aicompanion3. For the example app I built, the package name was appinventor.ai_ewpatton.WebviewHeaderTest. The resulting packet was 507 bytes, just 5 bytes short of the limit. If I had made my project name much longer, or had a longer email address, then I would have tripped the issue.
If you send me the version of Chrome you downgrade to in order to get the project to work, I might be able to give you some more insights into what exactly is going on when you upgrade Chrome, but the best course of action here is probably to reload the firmware on your ESP with a bigger allocation for header processing.