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

I don't think the spec is broken on 100-continue.

However, as a practical matter, how many servers *really* support the
mechanism? As far as I know, all major Java implementations
immediately send back a "HTTP/1.1 100 Continue\r\n\r\n" response if
the request carries header "Expect: 100-continue". Therefore they
support the feature on paper, yet completely defeat its purpose.

Zhong Yu

On Tue, Jul 17, 2012 at 3: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 Wednesday, 18 July 2012 15:48:47 UTC