Menu
If a response to a GET request doesn't have the Content-Length or Transfer-encoding: chunked field, what happens? How does the client know when the message ends?
306
The Content-Length is optional in an HTTP request. For a GET or DELETE the length must be zero. For POST, if Content-Length is specified and it does not match the length of the message-line, the message is either truncated, or padded with nulls to the specified length.
GET : The resource has been fetched and transmitted in the message body. HEAD : The representation headers are included in the response without any message body. PUT or POST : The resource describing the result of the action is transmitted in the message body.
HTTP Content-Length entity-header is used to indicate the size of entity-body in decimal no of octets i.e. bytes and sent it to the recipient. It is a forbidden header name. Basically it is the number of bytes of data in the body of the request or response. The body comes after the blank line below the headers.
The Content-Length header is mandatory for messages with entity bodies, unless the message is transported using chunked encoding. Content-Length is needed to detect premature message truncation when servers crash and to properly segment messages that share a persistent connection.
RFC 7230 section 3.3.3 contains a nice checklist of conditions for finding the message body size. Essentially it says the answer depends on what the status code is. The relevant conditions being #1 and #7.
"1. Any response ... with a 1xx (Informational), 204 (No Content), or 304 (Not Modified) status code is always terminated by the first empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message body."
"7. Otherwise, this is a response message without a declared message body length, so the message body length is determined by the number of octets received prior to the server closing the connection."
Its also worth knowing that the message may continue after the end of the body portion. RFC 7230 section 4.4 defines a Trailers feature where the payload may be followed by a second set of mime headers. If those exist the message ends where they do.
105
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
