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: Roberto Peon <grmocg@gmail.com>
Date: Tue, 17 Jul 2012 13:58:01 -0700
Message-ID: <CAP+FsNevVGh0ri7NaFvv5p_1CPxueocFcXFwmBMH+5Y5MT6F=w@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Osama Mazahir <OSAMAM@microsoft.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Adrien de Croy <adrien@qbik.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
I don't think the spec itself is broken; it is just difficult to get the
web as a whole to do it right, probably because it totally breaks
request-response assumptions. :(
-=R

On Tue, Jul 17, 2012 at 1:31 PM, Julian Reschke <julian.reschke@gmx.de>wrote:

> On 2012-07-17 21:45, Osama Mazahir wrote:
>
>> As it is currently, 100-continue is problematic.  The situation is tricky
>> because the client is not forced to wait for the 100/417/4xx (i.e. client
>> is allowed to timeout and send the entity body).  Thus, the server does not
>> have a deterministic way to now if the next byte after the double CRLF is
>> the first byte of the next request or the first byte of the entity body (of
>> the initial request).  This results in connections getting closed in
>> various edge/error cases.
>>
>> 100-continue is almost there but if we wanted to use it in a robust
>> manner in HTTP2 then I think we would have to revisit its specification.
>> ...
>>
>
> Well, we are revising RFC 2616, and if something is broken here we should
> consider to fix it. Or, minimally, document the problem.
>
> If I understand correctly, this will happen if the client sends "Expect:
> 100-continue", the server is slow to return an error status, and the client
> decides to give up waiting for the 100 status, and continues?
>
> Best regards, Julian
>
>
>
>
Received on Tuesday, 17 July 2012 20:58:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 July 2012 20:58:35 GMT