search

tass-belgium / picotcp-modules

Application level modules to run on top of the popular Embedded picoTCP TCP/IP stack
GNU General Public License v2.0
8 stars 11 forks source link

PsiControl: PicoTCP webserver not parsing the body of a HTTP POST request #3

Open BrechtN opened 9 years ago

BrechtN commented 9 years ago

firefox http post tcp stream ie http post request response tcp stream

ie http post request is split in different packets

Hello,

We currently have an issue with the PicoTCP webserver code when performing a HTTP POST request. When we send a POST request using internet explorer, this request is sent in 2 different packets:

packet 1 contains the header of this request: POST /eepromwrite HTTP/1.1 Accept: / Referer: http://192.168.100.150/eeprom.html Accept-Language: nl-be Accept-Encoding: gzip, deflate User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) Host: 192.168.100.150 Content-Length: 16 Connection: Keep-Alive Cache-Control: no-cache

packet 2 contains the body of the request: index=40&value=1

From what I can see, the PicoTCP HTTP server code reads the TCP stream and, once a HTTP header is received correctly, it calls up the user code to notify there is a new request. During this check for HTTP headers, the "readRemainingHeader" function of the picotcp server also scans if there isn't some body data and, if so, makes it available to the user code. If there was no body, it doesn't do anything and still calls the user code with "I have a new request". The user code then checks the request and asks picotcp if there is a body.

Now here's the trick: In firefox this request is sent in 1 packet, so when the picotcp code examines the request, the TCP stream has already received the body. It makes it available to our user code and we perform the action needed. In Internet Explorer however, this request is split in 2 packets, right after the header of the request. The picotcp server code inspects the header and sees there is no body data (yet), but still happily calls our user code.

In both cases, the header of the request indicates there is body data: "Content-Length: 16". So why does the picotcp code ignore this?

Please find some captures and screenshots attached.

Kind regards, Brecht

danielinux commented 9 years ago

Hi @BrechtN - Thanks for reporting. It looks like a bug indeed. As you know, we haven't tested these library extensively against IE.

I am putting this on the PicoTCP backlog, and it will be fixed as soon as we have some resource to assign to it. If you think this is a showstopper or it gets urgent for you, please contact us and we will try to speed things up.

BrechtN commented 9 years ago

Hi @danielinux,

Do you have an idea when this issue will be fixed? There is a release of our software planned at the end of February.

Kind regards, Brecht

danielinux commented 9 years ago

Hello @BrechtN - One resource is currently assigned to fix this. We have a test failing with wget as well, so this should be quicker to debug.

Thanks for the report, we'll keep you posted.

danielinux commented 9 years ago

@dpmik we are changing owner for this (bert). Can you update this issue with your latest findings? Thanks

danielinux commented 9 years ago

https://tools.ietf.org/html/rfc7230#section-3.3.2

eco747 commented 8 years ago

+1 for me

robbinvandamme commented 8 years ago

@bertdewaele, are you (bert) who looked into this?