Subject: WGLC issue: ambiguity in part 1 example

From: Amos Jeffries <[email-masked]>
Date: Sun, 17 Feb 2013 14:27:46 +1300

Part 1 section 2.1 example server response contains an entity body and a 
Content-Length header.

The Content-Length header is 2 bytes larger than the visible/printable 
bytes in the entity and it is not made clear that there are invisible 
trailer bytes being included in the in the displayed entity size.

I think at this early stage of the texts it would be best to keep things 
simple and only have the Content-Length equal to the visible bytes - 
"Hello world!" being 12 bytes long.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Feb 2013 11:13:43 +1100

Thanks, Amos; I've created an editorial ticket - 
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/433

Cheers,

On 17/02/2013, at 12:27 PM, Amos Jeffries <[email-masked]> wrote:

> Part 1 section 2.1 example server response contains an entity body and a Content-Length header.
> 
> The Content-Length header is 2 bytes larger than the visible/printable bytes in the entity and it is not made clear that there are invisible trailer bytes being included in the in the displayed entity size.
> 
> I think at this early stage of the texts it would be best to keep things simple and only have the Content-Length equal to the visible bytes - "Hello world!" being 12 bytes long.
> 
> Amos
> 

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Feb 2013 14:22:34 +0100

On 2013-02-18 01:13, Mark Nottingham wrote:
> ...

Fixed by keeping the example, but adding a note mentioning the trailing 
CR LF (<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2185>).

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 26 Feb 2013 15:27:22 -0800

> I think at this early stage of the texts it would be best to keep things simple and only have the Content-Length equal to the visible bytes - "Hello world!" being 12 bytes long.

Note that the extra two bytes (for CR LF) is intentional and produced
automatically by the xslt example body processor.  I believe it is
useful to show the real protocol and let the reader figure out why
all the bytes aren't visible.

....Roy

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 27 Feb 2013 16:20:07 +1300

> all the bytes aren't visible.

That is exactly the wrong thing to do at this point in the spec IMHO. 
This is the readers first exposure to the protocol - with dozens of 
pages ahead. They are not going to be bothered stopping to figure out 
something that fundamental. Probably they write their own 
sender/receiver to test with both "working perfectly" despite assumption 
flaws .

Leaving them to guess lends itself to confusion later if they assume 
wrong. I have had a number of conversations with people who wrongly came 
to the assumption that message bodies had to end with CRLF and had 
interoperability problems because of:
  - hanging connections waiting for CRLF which are not going to appear.
  - pipeline failure because server wants CRLF but receives "GE" from 
"GET /next.request HTTP/1.1" ... with Content-Length value too big for 
the entity.
  - pipeline failure because the sender emits CRLF without including 
them in the Content-Length value - a nasty "loose" frame parser is 
mandatory when facing these clients.
  - resource PUT/POST/GET failure because sender appends CRLF into 
binary objects screwing up the checksum.

Notice how the *best* outcome is that pipelining gets broken. :-( grr.

For the record I'm happy with the new -22 text explaining where they are 
and that they are *part* of the entity body. But please, no guessing 
when it comes to framing details. It needs to be black and white or we 
will continue to see these mistakes.

Amos

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 27 Feb 2013 00:09:44 -0800

On Feb 26, 2013, at 7:20 PM, Amos Jeffries wrote:

> That is exactly the wrong thing to do at this point in the spec IMHO. This is the readers first exposure to the protocol - with dozens of pages ahead. They are not going to be bothered stopping to figure out something that fundamental. Probably they write their own sender/receiver to test with both "working perfectly" despite assumption flaws .

No, assuming that all bytes are visible is naive.  I simply don't
care to support the notion that a protocol developer who is concerned
enough to actually count out the printed bytes in the example won't be
able to figure out that not all bytes are visible, because it isn't
a scenario based on reality (as you demonstrated yourself).
A text/plain document is supposed to always end in a CRLF in
order to be interoperable across multiple operating systems,
which is why the example does so.

I have zero interest whatsoever in supporting developers who
implement according to one and only one example, without reading
the many sections in the same document on how to parse.  That
is not the audience of an IETF spec.

And now I have to go fix the two grammatical errors added in

  (Note that the content length includes the trailing CR/LF
   sequence of the body text)

just because of an unnecessary last-minute addition.

....Roy