Re: [lwip-users] Bug on lwIP TCP section (or HTTP client from contrib)?

[Enrico Murador - Research & Development - CET]

Dear Sergio,

My replies below:

On 10/11/2015 19:07, Sergio R. Caprile wrote:
> Enrico,
> can you provide a trigger ? My wireshark screen is all green...
> I mean, please provide an HTML that I can include in my code that you
> know forces this behaviour.
...And after I tried a long time to make the bug happen again with 
Firefox, I found the truth...
Oops! I'm very sorry, I was absolutely sure I used Firefox for this 
test, but from the original wireshark log I found I used Chrome! You can 
see it from the GET header on my posted log.

...And in fact Chrome (version 34.0.1847.131) still does the issue. I've 
attached one 401.html page you can use for the test; anyway, I think any 
page with some text after the header will do the trick.
> I remember getting RSTs when POSTing to authorization required pages,
> the browser sends the whole pack and the server stops immediately. This
> is my fault and I will address it some day, but what you describe is
> exactly the opposite, the client sends FIN+ACK. I'm I correct ?
Yes. The (Chrome!) client sends FIN+ACK without waiting the HTTP message 
body. I've attached another Wireshark log. From it you can see that 
client sends FIN+ACK after receiving header, also if it contains a 
non-zero "Content-Length" field (I've managed to add a "Content-Length" 
field for all non-SSI replies).

Just for curiosity: interestingly, with Chrome you do not even have to 
type all the server URL on address bar: if you have auto-completion, 
when you hover the mouse on the suggested URL (provided you have it in 
the browser's history, of course), an HTTP get request automatically 
starts "under the hood"...
> I've tested with Firefox 41.0.2 and now 42.0 on Windoze, and my test bed
> is my lwHTTPd over the minimal unix port.
> My LWIP_HTTPD_SUPPORT_EXTSTATUS is #defined to 0
> My server sends the 401 header and status in one TCP segment in one
> Ethernet frame. Please provide your config too; I don't quite get the
> issue (my fault, not yours), but I seem to understand from what you
> describe that the 401 header is on one frame and the HTML status on the
> next one ? My code is optimized not to do that unless memory is scarce.
I think you must send two separate TCP packets (one for header and one 
for body). Then (if I'm not wrong), when the server receives the FIN+ACK 
for the header packet, it sends the second packet and asks TCP to close 
the connection (to send FIN together with the packet) but TCP complains 
that there is still unacked data (1 byte) on receive side (the FIN flag 
sent by client counts 1, and it has yet to be subtracted to unacked data 
because the "sent" callback is called first), so TCP sends RST to the 
client.

Sorry again for the browser mistake!

Enrico

401.zip
Description: Zip compressed data

TCP_RST_issue #2.pcapng
Description: Binary data