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