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

[BrechtN]

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]

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]

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]

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]

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

[danielinux]

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

[eco747]

+1 for me

[robbinvandamme]

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