If a HTTP/1.0 client requests Connection: keep-alive, will it understand chunked encoding?

Question

If my HTTP server gets an HTTP/1.0 request with the "Connection: keep-alive" header, is it a fair bet that the client will understand "Transfer-Encoding: chunked"?

Essentially, I'm trying to decide whether to honour the "Connection: keep-alive" header from HTTP/1.0 clients. If I do honour it, then I have to use chunked coding for the reply, because I can't buffer the entire reply in order to calculate a Content-Length header.

If it is not safe to expect that an HTTP/1.0 client that requests "Connection: keep-alive" will also understand chunked coding, then I will have to close the connection after each reply. (Or have I missed something?)

Answer 1

This is a definitive "No." Quote from the spec:

However, a persistent connection with an HTTP/1.0 client cannot make use of the chunked transfer-coding, and therefore MUST use a Content-Length for marking the ending boundary of each message.

-- RFC 2068 §19.7.1

Answer 2

Definitely not, given that the Transfer-Encoding is only in HTTP 1.1. Given your situation, I don't think you can really support the Connection: keep-alive header for an HTTP 1.0 client (for your use case, it's otherwise supported by HTTP 1.0). You should just ignore it and close the connection. You will be safe doing that since it's really just an optimization.

Answer 3

No chunked transfer-encoding is possible in HTTP 1.0. Keep-alive requests with chunked transfer-encoding is actually one of the defining differences between HTTP 1.0 and 1.1.

In order for the server to be able to use some feature that not all clients support like keep-alive or chunked transfer encoding, it would have to know prior to starting its response that the client is compatible with that feature, because there is no ongoing two-way communication between client and server after the initial request.

• Keep-alive itself can be supported in HTTP 1.0 because the client can include a Keep-Alive header in the request, indicating to the server that the client supports it.

• There is no established way for an HTTP 1.0 client to indicate that they support chunked transfer-encoding, so it's not possible for a server to send chunked responses to HTTP 1.0 requests. If you were to send a chunked response to a client that doesn't understand it, the client will receive garbage.

  When HTTP 1.0 uses keep-alive, it does so without chunked transfer-encoding.

• When keep-alive cannot use chunked transfer-encoding, it must send a Content-Length header for every response. This means that keep-alive can only be possible in HTTP 1.0 if the server knows the content length of the response at the start of the response in order to generate a valid Content-Length header. This may not be the case when the response is generated by a script and the server does not buffer it in its entirety before sending it.

  If a server doesn't know the content-length of a response before starting to send it, the server simply disables keep-alive for that response. It is not mandatory for a server to make every response a keep-alive response when it can.

• It is mandatory for HTTP 1.1 clients to support both keep-alive and chunked transfer-encoding, so when making an HTTP 1.1 request the client simply specifies HTTP/1.1 as the protocol and does not specify a Keep-Alive header.

  In practice, the client may still send the keep-alive header so it can use keep-alive even if the server supports only HTTP 1.0. If the server supports HTTP 1.1 or higher that header will be ignored and the HTTP/1.1 protocol indicator takes precedence. Note: I believe it would be very rare for a server today not to support HTTP 1.1 or higher, but to still support keep-alive, so sending that would rarely be useful.