Re: [lwip-users] http server: receiving more than one packet

[Mike Kleshov]

> sometimes a http transfer uses several packets. So I must know when the last
> packet is received to start answering. So far I search 'Content-Length' in
> the 1st packet and subtract the length of each packet. This causes problems
> if the string is not in the 1st packet, or the transmission is terminated
> from the remote side.

Those are only some of the problems this can cause. It is perfectly
legal for the web server to send data 1-byte-per-packet. You have to
be prepared for that if you want to be a well-behaved network node.

> Is there any other way to recognize the last packet?

The HTTP spec tells you how to do it.
Some notes on HTTP message length:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
Basically, you should use the chunked transfer encoding. It tells you
when the message ends.
Description of the chunked transfer encoding:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1

> I think the err callback is called when remote terminates a connection. Is 
> this correct?

If you are using the raw API, the tcp_recv() callback with pbuf==NULL
will be called when the remote side closes connection.
tcp_err() callback is called when connection is aborted due to some
error. If I am not mistaken, it is also called when the remote side
aborts the connection by sending an RST packet, but that's not the
same as closing connection.

Regards,
- mike