> From: openssl-users [mailto:openssl-users-boun...@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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
