Re: [Editorial Errata Reported] RFC7230 (4281)

On Feb 26, 2015, at 9:26 PM, RFC Errata System wrote:

> The following errata report has been submitted for RFC7230,
> "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7230&eid=4281
> 
> --------------------------------------
> Type: Editorial
> Reported by: Demian Brecht <demianbrecht@gmail.com>
> 
> Section: 3.3.2
> 
> Original Text
> -------------
> For messages that do not include a payload body, the Content-Length
> indicates the size of the selected representation (Section 3 of
> [RFC7231]).
> 
> Corrected Text
> --------------
> For outbound messages that do not include a payload body, the
> Content-Length indicates the size of the selected representation
> (Section 3 of [RFC7231]).
> 
> Notes
> -----
> Assuming my interpretation is correct, this phrase as-is is a little confusing given the next paragraphs states:
> 
> "A user agent SHOULD NOT send a Content-Length header field when the request message does not contain a payload body and the method semantics do not anticipate such a body."
> 
> The former is ambiguous, the latter explicit.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC7230 (draft-ietf-httpbis-p1-messaging-26)
> --------------------------------------
> Title               : Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
> Publication Date    : June 2014
> Author(s)           : R. Fielding, Ed., J. Reschke, Ed.
> Category            : PROPOSED STANDARD
> Source              : Hypertext Transfer Protocol Bis
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG

REJECTED

What the full paragraph says is:

   When a message does not have a Transfer-Encoding header field, a
   Content-Length header field can provide the anticipated size, as a
   decimal number of octets, for a potential payload body.  For messages
   that do include a payload body, the Content-Length field-value
   provides the framing information necessary for determining where the
   body (and message) ends.  For messages that do not include a payload
   body, the Content-Length indicates the size of the selected
   representation (Section 3 of [RFC7231]).

There is no reason to narrow the last sentence to "outbound messages"
(nor, more accurately, to "responses"), because "messages that do not
include a payload body" is the only relevant characteristic.  What we
have here is a summary of the field's semantics given the message framing
algorithm, as described in the remainder of that section and 3.3.3.
The question it answers is "I have a content-length in a message that
does not include a payload body, what does it mean?" (knowing that, in all
other cases, content length means the length of the payload body.)

Naturally, the normative requirements are more specific and narrowed to
the distinct cases of requests and responses, which prevents a valid
inbound (request) message from containing a Content-Length header
field unless that message does include a payload body.

....Roy

Received on Friday, 27 February 2015 18:14:11 UTC