{"question":"How does a recipient determine the length of a message body in an HTTP/1.1 message?","state":"partial","http_status":200,"index_version":"0fc1763d6701","answer":"In rfc9112#6.3, any response to a HEAD request and any response with a 1xx, 204, or 304 status code is terminated by the first empty line after the header fields and therefore cannot contain a message body or trailer section. [rfc9112#6.3] In rfc9112#6.3, any 2xx response to a CONNECT request means the connection becomes a tunnel immediately after the empty line ending the header fields, and the client must ignore any Content-Length or Transfer-Encoding fields in that message. [rfc9112#6.3] In rfc9112#6.3, if a message contains both Transfer-Encoding and Content-Length, Transfer-Encoding overrides Content-Length. [rfc9112#6.3] In rfc9112#6.3, an intermediary that forwards a message containing both Transfer-Encoding and Content-Length must remove the received Content-Length field and process the Transfer-Encoding before forwarding the message downstream. [rfc9112#6.3] In rfc9112#6.3, if Transfer-Encoding is present and chunked is the final transfer coding, the message body length is determined by reading and decoding the chunked data until the transfer coding indicates completion. [rfc9112#6.3] In rfc9112#6.3, if Transfer-Encoding is present in a response and chunked is not the final transfer coding, the message body length is determined by reading the connection until the server closes it. [rfc9112#6.3] In rfc9112#6.3, if Transfer-Encoding is present in a request and chunked is not the final transfer coding, the message body length cannot be determined reliably and the server must respond with 400 Bad Request and close the connection. [rfc9112#6.3] In rfc9112#6.3, if a message has no Transfer-Encoding and has an invalid Content-Length, the message framing is invalid and the recipient must treat it as an unrecoverable error unless the field value is a comma-separated list whose values are all valid and identical. [rfc9112#6.3] In rfc9112#6.3, when an invalid Content-Length value can be parsed as a comma-separated list whose values are all valid and identical, the message is processed using that single value as the Content-Length value. [rfc9112#6.3] In rfc9112#6.3, if a valid Content-Length is present without Transfer-Encoding, its decimal value defines the expected message body length in octets. [rfc9112#6.3] In rfc9112#6.3, if the sender closes the connection or the recipient times out before the number of octets indicated by Content-Length is received, the recipient must consider the message incomplete and close the connection. [rfc9112#6.3] In rfc9112#6.3, if the message is otherwise a response without a declared message body length, the message body length is the number of octets received before the server closes the connection. [rfc9112#6.3] In rfc9112#6.3, request messages are never close-delimited because they are explicitly framed by length or transfer coding, and the absence of both means the request ends immediately after the header section. [rfc9112#6.3]","message":"2 of 15 drafted claims were not supported by the passages they cited and have been withdrawn.","citations":["rfc9112#6.3"],"supported":[{"text":"In rfc9112#6.3, any response to a HEAD request and any response with a 1xx, 204, or 304 status code is terminated by the first empty line after the header fields and therefore cannot contain a message body or trailer section.","citation":"rfc9112#6.3","coverage":0.9545},{"text":"In rfc9112#6.3, any 2xx response to a CONNECT request means the connection becomes a tunnel immediately after the empty line ending the header fields, and the client must ignore any Content-Length or Transfer-Encoding fields in that message.","citation":"rfc9112#6.3","coverage":0.8571},{"text":"In rfc9112#6.3, if a message contains both Transfer-Encoding and Content-Length, Transfer-Encoding overrides Content-Length.","citation":"rfc9112#6.3","coverage":1.0},{"text":"In rfc9112#6.3, an intermediary that forwards a message containing both Transfer-Encoding and Content-Length must remove the received Content-Length field and process the Transfer-Encoding before forwarding the message downstream.","citation":"rfc9112#6.3","coverage":1.0},{"text":"In rfc9112#6.3, if Transfer-Encoding is present and chunked is the final transfer coding, the message body length is determined by reading and decoding the chunked data until the transfer coding indicates completion.","citation":"rfc9112#6.3","coverage":0.9375},{"text":"In rfc9112#6.3, if Transfer-Encoding is present in a response and chunked is not the final transfer coding, the message body length is determined by reading the connection until the server closes it.","citation":"rfc9112#6.3","coverage":1.0},{"text":"In rfc9112#6.3, if Transfer-Encoding is present in a request and chunked is not the final transfer coding, the message body length cannot be determined reliably and the server must respond with 400 Bad Request and close the connection.","citation":"rfc9112#6.3","coverage":1.0},{"text":"In rfc9112#6.3, if a message has no Transfer-Encoding and has an invalid Content-Length, the message framing is invalid and the recipient must treat it as an unrecoverable error unless the field value is a comma-separated list whose values are all valid and identical.","citation":"rfc9112#6.3","coverage":0.9444},{"text":"In rfc9112#6.3, when an invalid Content-Length value can be parsed as a comma-separated list whose values are all valid and identical, the message is processed using that single value as the Content-Length value.","citation":"rfc9112#6.3","coverage":0.8571},{"text":"In rfc9112#6.3, if a valid Content-Length is present without Transfer-Encoding, its decimal value defines the expected message body length in octets.","citation":"rfc9112#6.3","coverage":1.0},{"text":"In rfc9112#6.3, if the sender closes the connection or the recipient times out before the number of octets indicated by Content-Length is received, the recipient must consider the message incomplete and close the connection.","citation":"rfc9112#6.3","coverage":1.0},{"text":"In rfc9112#6.3, if the message is otherwise a response without a declared message body length, the message body length is the number of octets received before the server closes the connection.","citation":"rfc9112#6.3","coverage":1.0},{"text":"In rfc9112#6.3, request messages are never close-delimited because they are explicitly framed by length or transfer coding, and the absence of both means the request ends immediately after the header section.","citation":"rfc9112#6.3","coverage":0.9444}],"withdrawn":[{"text":"In rfc9112#6.3, a recipient determines the length of an HTTP/1.1 message body by applying the specified rules in order of precedence.","citation":"rfc9112#6.3","rule":"coverage below floor","detail":"0.64 of the claim's content words appear in rfc9112#6.3, below the 0.67 floor","coverage":0.6364},{"text":"In rfc9112#6.3, if the message is a request and none of the preceding rules applies, the message body length is zero.","citation":"rfc9112#6.3","rule":"coverage below floor","detail":"0.67 of the claim's content words appear in rfc9112#6.3, below the 0.67 floor","coverage":0.6667}],"consulted":[{"section_id":"rfc9112#6.3","citation":"RFC 9112 Section 6.3: Message Body Length","rank":1,"score":0.7299},{"section_id":"rfc9112#6","citation":"RFC 9112 Section 6: Message Body","rank":4,"score":0.7035},{"section_id":"rfc9110#2.3","citation":"RFC 9110 Section 2.3: Length Requirements","rank":7,"score":0.641},{"section_id":"rfc9110#8.6","citation":"RFC 9110 Section 8.6: Content-Length","rank":8,"score":0.6306},{"section_id":"rfc9112#2.1","citation":"RFC 9112 Section 2.1: Message Format","rank":9,"score":0.6297},{"section_id":"rfc9112#6.2","citation":"RFC 9112 Section 6.2: Content-Length","rank":10,"score":0.6039}],"budget":{"deadline_ms":150.0,"elapsed_ms":15.316,"exceeded":false,"stages":{"retrieval":0.4,"drafting":0.004,"grounding":14.866}}}