RE: HTTP2 Expression of Interest : Squid

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.

-----Original Message-----
From: Julian Reschke [] 
Sent: Tuesday, July 17, 2012 10:18 AM
To: Gabriel Montenegro
Cc: Adrien de Croy; Poul-Henning Kamp; Amos Jeffries;
Subject: Re: HTTP2 Expression of Interest : Squid

On 2012-07-17 19:02, Gabriel Montenegro wrote:
>> From: Adrien de Croy []
> ...
>> I agree, and actually I'd be keen to apply this philosphy in both 
>> directions, where no significant resource is transmitted in either 
>> direction without the recipient indicating prior willingness (either 
>> by requesting it, or indicating willingness).  What I'm getting at 
>> here is large POST / PUT requests.  Currently it's a mess esp with auth in the mix.
> Along these lines, to help with a  POST/PUT with auth in the mix we mentioned an idea in our authentication EoI of a lightweight probe:

> 1.       Lightweight "probe" for POSTs and PUTs.  Initial PUTs and POSTs with long entity bodies will cause problems because of the extra round trip required by authentication. ("Initial" means when first request on a connection is PUT or POST). If the body is indefinite length, it may not be able to be recreated. This is a problem with any multi-legged authentication scheme in HTTP. It could be avoided if there were a guaranteed benign request type that could be used to force authentication if needed before doing the PUT or POST.

We have

   Expect: 100-continue

for that, no?

Best regards, Julian

Received on Tuesday, 17 July 2012 19:45:47 UTC