Hallo, gentle people,
Need some help with viewing esp32 cam stream on my app.
When i open ip on pc/phone’s browser everything works. With mit app browser it doesn’t and gives me “header fields are too long for server to interpret” error.
When i try media player (with rtsp code for mjpeg on esp32) it doesn’t work neither.
Any help would be appreciated.
Hi
“header fields are too long for server to interpret”
That sounds familiar. A solution, if possible, would be to allocate a bigger memory buffer on the ESP 32 firmware for the header fields. The default is probably 512 bytes but that can easily be exceeded unfortunately.
Alternatively, a work-around would be to use Activity Starter to run the phone’s default browser.
Two different headers were increased from 512 to 1024 and from 1024 to 2048. Will now try the activity starter. Thanks
is it possible to have activity started in the same screen (part of it as with app browser) were my all other interface items are placed?
It isn’t - hence it’s status of “workaround” rather than “solution”.
The headers sent are too long. If we can’t increase the memory buffer on the ESP 32, I wonder If we can reduce the content in the header fields to respect the 512 byte limit.
What exactly is your setup? Do you have an ESP 32 + microcontroller (e.g. Arduino) + Camera, or is the Camera built into an ESP 32 (e.g. Ai-Thinker CAM board)
Hi. It is the later " Camera built into an ESP 32 (e.g. Ai-Thinker CAM board)" and i would like to see stream on part of the screen. But activity starter prompts me a full screen.
I am compiling kind of fpv robot control app 
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:
Hi Frank,
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.
Test apparatus:
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
Host: xxx.xxx.x.xxx:8000
Connection: keep-alive
Upgrade-Insecure-Requests: 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: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
X-Requested-With: edu.mit.appinventor.aicompanion3
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
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:
26
24
30
173
128
52 << this is the X-Requested-With header
32
33
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.
Regards,
Evan
Very good, thank You so much. I should have done a better search.
Hi Evan
Can we not define our own GET headers to ensure the 512 byte limit is met?
You can add headers, but the base set of headers is set by the underlying webview implementation (Chrome in most cases). The only one we might be able to control would be the UserAgent and blanket changing it might have unintended consequences for other users.
There are similar boards available with a much larger memory, so I think at the end of the day that’s the solution - use a different board.
My app worked a couple of months back with the esp32 cam you have downgraded your app
is that fair
Hello Tzvi
Can you give a more detailed description of the issue? For a start, what is it that has been downgraded?
my app wored a couple of months back
These lines were enough to to disply my esp 32 cam image and video in the app .
I have not changed anything since then.
and now they just don't work they stopped working on my already downloaded app about a month back .
I know my camera is fine because I tried it on the web and it worked fine.
Do you get any error of type "header fields are too long for server to interpret"?
when i try to connect to the camera Now I'm getting a message.
Header fields are too long for server to interpret.
That might possibly be a change by Google (Web Viewer). One snag is that anything http is treated with suspicion.
However, a more advanced WebViewer is available as an extension, it might be able to deal with longer headers. Certainly, it is worth a try. Make a copy of your project first as the extension works a bit differently.
http://sunnythedeveloper.epizy.com/2020/05/13/customwebview-an-extended-form-of-web-viewer/
Does that IP address still work in a web browser?
Maybe your router's DHCP assigned it a different local address?
Whoa Horsey - you have not done anything at all to the ESP32 board? The solution last time was a wrapper for the camera library:
Try Frank Bröker's solution:
