chunked encoding and connection:close together
Asked Answered
W

2

5

I'm a bit confused about what to do with the "Connection" header when using chunked-encoding. Shall the "Connection" header not be added (or set to keep-alive, which is the same as we're talking about HTTP 1.1) or is this authorized to set it to Connection:close Sending an empty chunk, means the end of the transfer, but does it mean the end of the connection? I thought that I would need to add Connection:close when my intention is to close the connection after an empty chunk has been sent where if I don't add the Connection header, it would remain open

Thanks

Weeds answered 1/5, 2018 at 3:47 Comment(0)
L
6

Message Length and Connection Management are two different things that really have nothing to do with each other (except in the one case where the Message Length is completely unknown and closing the connection is the only possible way to denote EOF, but that rarely happens, and is not your situation).

Chunking only applies to Message Length, where a 0-length chunk denotes EOF. If the connection is closed prematurely before EOF is reached, the Message is incomplete, and the receiver can decide whether to keep/process it or not.

The Connection header is used by the client to specify whether it wants the server to close the connection, or leave it open, after sending its response. The same header is used by the server to specify whether the connection is actually closing or staying open after the response has been sent.

Shall the "Connection" header not be added (or set to keep-alive, which is the same as we're talking about HTTP 1.1) or is this authorized to set it to Connection:close

That has nothing to do with chunking. Regardless of the format of the Message, the client and server should always indicate their intentions for the current connection, whether it should be closed or left open. That is done via the presence of, or lack of, a Connection header, depending on the HTTP version:

If HTTP 1.0 is used, the default behavior is close unless Connection: keep-alive is explicitly sent.

If HTTP 1.1+ is used, the default behavior is keep-alive unless Connection: close is explicitly sent.

If the client requests a keep-alive, the server decides whether or not to honor it. The server may either leave the connection open, or it may close the connection.

If the client requests a closure, the server MUST honor it and close the connection.

Sending an empty chunk, means the end of the transfer, but does it mean the end of the connection?

No. Only the Connection header does that. Especially in a keep-alive scenario, thus the connection is left open so the client can reuse the existing connection to send a new request after the transfer of the previous response is finished.

I thought that I would need to add Connection:close when my intention is to close the connection after an empty chunk has been sent

Correct, especially in HTTP 1.1+ where keep-alive is the default behavior.

where if I don't add the Connection header, it would remain open

The meaning of an omitted Connection header depends on the HTTP version being used, as described above.

Lachrymator answered 1/5, 2018 at 22:4 Comment(3)
Thanks - So these are not correlated, as suspected. I'm surprised to see how many clients claim to be HTTP 1.1 and do not support chunked-encoding. I think it's pretty clear that it's mandatory. And I should have added that I was only talking about HTTP 1.1Weeds
It is mandatory for all HTTP 1.1 clients to recognize chunked responses, but it is not mandatory for them to send chunked requests (though it is mandatory for all HTTP 1.1 servers to recognize them).Lachrymator
And that's the problem I was facing. Some clients claim to be HTTP 1.1 in their GET request and when I respond with chunked, they close the connection immediately. Clients are some UPnP-capable speakers. Bad implementation I guessWeeds
L
1

A server is allowed to send Connection: close while using chunked transfer encoding, this should not cause clients to disconnect before the response is finished.

According to RFC2616 https://www.rfc-editor.org/rfc/rfc2616#section-14.10

For example,

   Connection: close

in either the request or the response header fields indicates that the connection SHOULD NOT be considered `persistent' (section 8.1) after the current request/response is complete.

Since the response is not complete while chunks are being sent, the connection is not forbidden from persisting.

Lipcombe answered 27/3, 2020 at 0:13 Comment(1)
Remy Lebeau's answer is more comprehensive than this, but reading it quickly did not leave me certain of the answer to this question before testing it.Lipcombe

© 2022 - 2024 — McMap. All rights reserved.