I have to correct what I wrote. If the value of Content-Length header sent by the server is less than the real data exchanged, the client will not accept other data (if Content-Length says 10, the client will receive up to 10, no more). If the value is greater than the real content length, the browser emits a "content length mismatch error".1. I don't know the content length in advance. So I have to start with a length that is surely greater than the final length, otherwise the browser stops receveing data before the end. However what happens if Content Length header says 300 and only 100 bytes were received? Chrome seems ok, but other browsers? Is there a standard behaviour? From RFC7230 it seems sending a Content Length value greater than real message body length isn't good: /5. If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the expected message body length in octets. If the sender closes the connection or the recipient times out before the indicated number of octets are received, the recipient MUST consider the message to be incomplete and close the connection./ Is it possible to avoid sending Content Length header for log.json file? Consider I'm using dynamic headers.
In other words, if appears, content length must report the exact content length. In my case, because I don't know the real content length in advance, I should avoid sending Content Length header. However I don't know if it is possible in httpd.
In get_http_headers(), there's the possibility to skip content-length, but it is only for SSI files and for files with included headers.
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
