You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on tcpdump, it looks like some local servers I've been using for testing purposes split their response and end up with the HTTP/1.1 200 OK in one TCP fragment and the remainder of the fragment separately. Using the exact same app (e.g. with Python Flask, but also tested with others), if the TCP fragment is split up this way, any other browser or curl is able to reassemble the packets and gets a whole response, but my Espduino only gets the contents of the first packet, after which it waits 5 seconds and times out, reporting a 0 response code.
I added a line to the tcpclient_recv function in rest.c to help debug:
INFO("DEBUG:\n%s\n\n", pdata);
And the output as I anticipated is EXTRA DEBUG: HTTP/1.1 200 OK (but nothing else) when the TCP packet is split (they consistently end up getting split right after this part, with the remainder of headers and the body in the next packet).
When the TCP packet is not split (because I'm serving through nginx or mitmproxy, which join the split packets), the response for the exact same code is:
EXTRA DEBUG: HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 38
this: that
Server: Werkzeug/0.10.4 Python/3.4.3
Date: Mon, 14 Sep 2015 07:17:15 GMT
<html><body>hello world!</body></html>
I'm going to work on trying to figure out why it isn't handling split packets like other apps do.
The text was updated successfully, but these errors were encountered:
Apologies in advance for improper terminology, I know next to nothing about TCP / IP / ICMP.
I think I have figured out that an issue I thought was with Espduino is actually a problem with how this library handles TCP fragments.
Based on tcpdump, it looks like some local servers I've been using for testing purposes split their response and end up with the
HTTP/1.1 200 OKin one TCP fragment and the remainder of the fragment separately. Using the exact same app (e.g. with Python Flask, but also tested with others), if the TCP fragment is split up this way, any other browser or curl is able to reassemble the packets and gets a whole response, but my Espduino only gets the contents of the first packet, after which it waits 5 seconds and times out, reporting a0response code.I added a line to the
tcpclient_recvfunction inrest.cto help debug:And the output as I anticipated is
EXTRA DEBUG: HTTP/1.1 200 OK(but nothing else) when the TCP packet is split (they consistently end up getting split right after this part, with the remainder of headers and the body in the next packet).When the TCP packet is not split (because I'm serving through nginx or mitmproxy, which join the split packets), the response for the exact same code is:
I'm going to work on trying to figure out why it isn't handling split packets like other apps do.
The text was updated successfully, but these errors were encountered: