editorial improvements to message length definition

[julian.reschke@…]

5. If a valid Content-Length header field is present without

Transfer-Encoding, its decimal value defines the message body length in octets. If the actual number of octets sent in the message is less than the indicated Content-Length, the recipient MUST consider the message to be incomplete and treat the connection as no longer usable.

The only way the sender could have sent fewer than the indicated number of octets would be if it closed the connection early, in which case telling the receiver to "treat the connection as no longer usuable" is hardly necessary. Maybe:

If the sender closes the connection or the recipient times out before the indicated number of octets are received, then the recipient MUST consider the message to be incomplete and treat the connection as no longer usable.

If the actual number of octets sent in the message is more than the indicated Content-Length

This is impossible by definition; any octets after the indicated Content-Length are not part of the message.

the recipient MUST only process the message body up to the field value's number of octets; the remainder of the message MUST either be discarded or treated as the next message in a pipeline. For the sake of robustness, a user-agent MAY attempt to detect and correct such an error in message framing if it is parsing the response to the last request on a connection and the connection has been closed by the server.

As above, "user agent" shouldn't have a hyphen, but it should be "client" here anyway, shouldn't it?

Maybe replace the whole paragraph with:

For the sake of robustness, a client MAY assume that any additional octets after the indicated Content-Length in the response to the last request on a connection were intended to be part of the message body.

[fielding@…]

From [2036]:

(editorial) improvements to message length definition; addresses #392