Using the new Arduino IDE for ESP8266 and found bugs, report them here

Moderator: igrr

User avatar
By easy123
#45476 Hello all ESP8266ers from across the world,

I'm executing the (vanillia) "AdvancedWebServer" example sketch. which is using ESP8266WebServer class.

I have found that if I make a POST request on the ESP8266WebServer the arguments are not always "readable" with the server.args(); method.

I'm using a simple .NET application that I wrote as a client for this server.

The problem occurs if I launch the application for the first time, or if there's an interval of several minutes between the POST requests.

When it "doesn't work" I get the following output from the example sketch :
Code: Select allFile Not Found

URI: /myURI
Method: POST
Arguments: 1
 plain:


instead of the expected (which happens most of the time) :
Code: Select allFile Not Found

URI: /myURI
Method: POST
Arguments: 2
l:mytest
z:secondargs


After looking at the difference of the sent TCP packets with WireShark,
I have found that in the case when it works well, the HTTP packet is transmitted at once with the POST payload in the same packet.
When it doesn't work, the packet seems to be splitted in two parts, the POST payload being sent after the first packet which contains additionnal header : "Connection:KeepAlive" and WireShark info says [TCP segment of a reassembled PDU] for this packet.

I have tried several ways in .NET application and could achieved to force the POST payload always be in the same packet.

In this case, how can I read the POST payload with the ESP8266WebServer class ?

Best regards.
MEB
User avatar
By easy123
#45517 I have found the cause of the problem.
It's the header Expect100Continue that makes this behaviour.
The client sends the request header first, then waits for the server to respond "100" to send the POST datas.
So I think this behaviour should be implemented in ESP8266WebServer Class in order to correctly handle this requests.

In .NET I had to use the following property for HttpWebRequest class, in order to make it work :
.ServicePoint.Expect100Continue = false;