W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: WGLC issue: ambiguity in part 1 example

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 27 Feb 2013 16:20:07 +1300
Message-ID: <512D7B67.9030707@treenet.co.nz>
To: ietf-http-wg@w3.org
On 27/02/2013 12:27 p.m., Roy T. Fielding wrote:
> On Feb 16, 2013, at 5:27 PM, Amos Jeffries 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.
> 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

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.

Received on Wednesday, 27 February 2013 03:20:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC