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

[Enrico Murador - Research & Development - CET]

Update: now I've found why Chrome sends the FIN+ACK after the header 
(also after I added the Content-Length field to that header). Server was 
telling the client that reply was in HTTP 1.0, and Chrome doesn't take 
care of the Content-Length field unless reply is in HTTP 1.1 (and maybe 
this is correct behavior).

To avoid this kind of issues, I think the lwIP HTTP server should 
automatically add the Content-Length field for, at least, all HTTP 1.1 
non-SSI packets. Maybe I'll post a "feature request" for this.

Anyway, the TCP "off-by one window" issue still remains, although maybe 
it is not of severe importance. And to reproduce the issue, apart from 
sending a 401 reply in two chunks, the header must indicate "HTTP 1.0".

My replies to your questions follows:

On 11/11/2015 13:48, Sergio R. Caprile wrote:
> As a matter of fact, if I'm not wrong, it is the server who must close
> the connection and not the client, so this is Chrome's bug.
I don't know. But I've not yet seen a FIN sent from my server, at least 
on GET requests. It is always the client (tried with Chrome and Firefox) 
that ACKs the last packet and then sends FIN.
> However, you mentioned a "off by 1" in the window so I'll try to see
> that and what the culprit.
> Ciao
I've attached my actual lwipopts file. Anyway, I think the fastest way 
to reproduce the issue is to use a stock lwIP web server and modify the 
standard reply header, adding the "401 Unauthorized" row (with HTTP 1.0 
version header, see before).

Enrico

lwipopts.h
Description: Text document