Il 27/11/2017 20:38, address@hidden ha scritto:
Giuseppe
Modugno wrote:
[..] Why the server should close the
connection when the Content Length header is not send?
Because the client cannot reuse this connection to send more
requests as it doesn't know when the server is finished.
HTTP is defined to either get the content length from the number
of bytes received before the connection is closed or through some
other encoding (like the content-length header, chunked encoding,
etc.).
I think I got your point. You mean the same TCP connection can't be
reused for other HTTP requests after the body is
completely send (because the server has closed the connection). So
the client is forced to reopen a new TCP connection.
Of course you are thinking keep-alive support is enabled. In my
case, I was working without keep-alive support. After enabling
keep-alive support, my "solution" works (the server must send
Connection: Close when Content-Length isn't send), but there's the
drawback of closing connection.
I tried and it seems it works well:
Do you really expect me to download this image? If it's a
wireshark trace: PLEASE SEND A PCAP, NOT SOME SCREENSHOT!!
I'm sorry, I hoped an image would be much more "fast" to understand.
Again regarding asyncronous-read file, I think another small
improvement can be made. get_http_headers() is called too early,
when the file length couldn't be known. However it is known when
http_send_headers() will be called, because fs_is_file_ready() will
return true.
So my idea is to replace the content length value header
(HDR_STRINGS_IDX_CONTENT_LEN_NR) with the correct value
(hs->handle->len) during http_send_headers(). I made some
tests and it seems it works.
|