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

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 
> >MUST
> >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 :

http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-3.3.1

   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).

Regards,
Willy

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