[openssl-users] Shutdown details

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Viktor Dukhovni
>
> HTTP has a "Content-Length:" header or alternatively supports Chunked
> transfers.

For HTTP/1.1, RFC 2616 also allows the message body length to be determined by the use of the self-delimiting content-type such as multipart/byteranges. HTTP/1.0 permitted this for any self-delimiting content-type, but I don't know that I've ever seen an HTTP/1.0 implementation do it. (And messages which are not allowed to have a body, such as GET and HEAD, don't need to delimit the body, since there isn't one.)

Also relevant to Jordan's question:

- Nothing says the client has to do a half-close after sending the request. In fact, when HTTP/1.1 made persistent conversations the default, user agents mostly switched to keeping the conversation open after a request, until the server closed it or some idle timer expired.

- And, in fact, RFC 2616 implicitly *forbids* the client from using half-close to indicate the end of the response. The text oddly suggests the authors were unaware of half-close, though it's possible they simply wished to keep the same behavior if the transport didn't support half-close (as, indeed TLSv1.2 does not, if the specification is followed to the letter).

At any rate, RFC 2616 4.4 #5 says: " Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response." That's clearly wrong, for transports such as TCP that support half-close; but it handily eliminates any problem of a UA trying to delimit a request message-body with half-close when running over TLS.

--
Michael Wojcik
Distinguished Engineer, Micro Focus