W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: usability of 100-continue, was: HTTP2 Expression of Interest : Squid

From: Willy Tarreau <w@1wt.eu>
Date: Fri, 20 Jul 2012 09:08:08 +0200
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
Message-ID: <20120720070808.GI20313@1wt.eu>
On Fri, Jul 20, 2012 at 06:45:15PM +1200, Amos Jeffries wrote:
> The key word in there is probably "browser", the assumption that each 
> client is singular ("browser") and that each connection is singular 
> ("user") is very widespread.
> That is no reason for any compliant server to disconnect. Let the broken 
> servers do it, and let the correct servers gain the benefits of being 
> correct.

+1 on this.

> Referring to this part specifically: "the server should close the 
> connection (after draining possibly pending data), just as it would do 
> on a redirect to another domain"
> >From what I remember of my last reading of draft-19, it was clearly stated
> >that if a transfer-encoding other than chunked is present, then chunked 
> >be present last so the transfer is always chunk-encoded, precisely for this
> >issue. You can send safely reject messages which contain Transfer-Encoding
> >without "chunked" as the last one (you'd better recheck the spec than take
> >my word for it though).
> There is no mandate that chunked is *always* to be used with them 
> though. Only that when combined the best is last.

Yes, I just found it :


   If any transfer-coding is applied to a
   request payload body, the final transfer-coding applied MUST be
   "chunked". If any transfer-coding is applied to a response payload
   body, then either the final transfer-coding applied MUST be "chunked"
   or the message MUST be terminated by closing the connection.

> We have had to take that assumption on our own guess at good-practice in 
> Squid and decoded to always chunk 1.1 when content-length is missing. 
> Regardless of other encodings.

I think this was recent additions from http-bis (which is a very important one).

Received on Friday, 20 July 2012 07:08:40 UTC

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