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: Amos Jeffries <squid3@treenet.co.nz>
Date: Fri, 20 Jul 2012 19:37:54 +1200
Message-ID: <50090AD2.8030509@treenet.co.nz>
To: Willy Tarreau <w@1wt.eu>
CC: ietf-http-wg@w3.org
On 20/07/2012 7:08 p.m., Willy Tarreau wrote:
> 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".

Wait up!  there is an implication in here I overlooked.

"If any transfer-encoding is applied ... the final ... applied MUST be 
chunked."

That is not very clear, but definitely mandatory chunked encoding on 
requests. Which resolves all the weird edge cases by making the next 
bytes a chunked size field which is invalid requst-line syntax.


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

It would seem so.

Amos
Received on Friday, 20 July 2012 07:38:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 20 July 2012 07:38:35 GMT