Fix receiving of large HTTP headers #1415
Conversation
opichals
force-pushed
the
cope-with-http-headers-longer-than-mss
branch
from
48109e5
to
20a8bc1
Compare
opichals
changed the title
Added a test which sends HTTP headers which take more than MSS bytes (536) and therefore the httpParseHeaders() needs to be called later again after the next packet arrives. Fixes espruino#1405
opichals
force-pushed
the
cope-with-http-headers-longer-than-mss
branch
from
20a8bc1
to
faf7157
Compare
|
Thanks! Yeah, on non-linux/esp* devices the data tends to come in as much smaller chunks, so you hit this pretty much right away. |
|
Any idea what the 536 mss size is based on? |
|
@wilberforce I did some study there but lack complete understanding aside from the wikipedia MSS description at https://en.wikipedia.org/wiki/Maximum_segment_size |
|
I think it was to do with the packet size ESP8266 usually tried to deal with? In Espruino it's just the size of chunks of data that are sent to/from the IP layer. Raising it has reasonably minimal gains other than when transmitting, when the ESP8266/32 might choose to send a packet after every call to edit: basically 536 seemed to be a good toss-up between memory usage, overhead for Espruino, and wireless speed. Maybe the trade-off is different on ESP32 but you'd want to do a bunch of benchmarks before changing it :) |
Added a test which sends HTTP headers which take more than
MSS bytes (536) and therefore the httpParseHeaders() needs to be
called later again after the next packet arrives.
The websocket
Connection: Upgraderequest with theSec-WebSocket-*headers made the HTTP header section largeras described above so it exhibited in the websocket scenario in #1405