Subject: [Editorial Errata Reported] RFC7230 (4281)

From: RFC Errata System <[email-masked]>
Date: Thu, 26 Feb 2015 21:26:22 -0800 (PST)

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 <[email-masked]>

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Feb 2015 16:36:16 +1100

I think Roy wrote this text, but from my standpoint, it's REJECT -- Content-Length defines message length under these conditions no matter what the UA should or should not do.

> On 27 Feb 2015, at 4:26 pm, RFC Errata System <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 27 Feb 2015 08:12:27 +0100

On Fri, Feb 27, 2015 at 04:36:16PM +1100, Mark Nottingham wrote:
> I think Roy wrote this text, but from my standpoint, it's REJECT --
> Content-Length defines message length under these conditions no matter what
> the UA should or should not do.

Agreed. The proposal makes the text confusing while the original text
makes it quite clear how a message body's size is determined.

Willy

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 28 Feb 2015 00:32:56 +1300

> I think Roy wrote this text, but from my standpoint, it's REJECT -- Content-Length defines message length under these conditions no matter what the UA should or should not do.

Agreed. It also applies to messages regardless of whether they are
request, response, inbound or outbound.

Amos

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 27 Feb 2015 10:13:51 -0800

> "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".

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