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

[Enrico Murador - Research & Development - CET]

Dear Simon,

On 11/11/2015 15:25, Simon Goldschmidt wrote:

Enrico Murador wrote:

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).

This is not so much a version thing but a header thing. The server tells the client
whether it supports persistent connections. Although not really standard, they work
in 1.0, too.

I'm not an expert on this. Do you mean that I should not see that behavior if my server tells the client that it supports persistent connections?
And I have another question: is it OK from the server to tell it supports persistent connections, when it does not insert the Content-Length field in the header?

Aside from that, it should be OK for the client to close the connection before the
server has sent all bytes. Only it must be prepared to receive a RST in this case,
which tells the client that the connection was not gracefully closed (on the server
side in this case).

Being like that, I don't see a problem with what you observed.

Effectively the client does not complain, after receiving RST.
Anyway when my server sends RST, it does that because it has only 1 byte unacked, so it seems that all the data sent from server (whole 401 reply, header and body) has been acked, and maybe TCP should not send an RST.

Side note and another question (maybe related to this issue):
I waited to file this "maybe bug" because I was thinking if calling tcp_close() at the same time the last TCP packet is sent (this happens when HTTP wants to add a "FIN" to the last data packet) could lead to other problems.
E.g, I was trying to sort out why, when running out of listening pcbs, my TCP sometimes closes a "TIME-WAIT" connection that, from Wireshark logs, should not be in that state, because server has yet to send the very last TCP packet (the one that should have the FIN flag active).

Could this be caused from tcp_close() setting the pcb in TIME_WAIT state, and then it could happen that a call to tcp_alloc() frees the TIME_WAITing pcb (when running out of pbufs) before last data packet has been passed to the network driver?

Thank you
Enrico