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

On Fri, Jul 20, 2012 at 12:32:11AM +0000, Osama Mazahir wrote:
> > I think we should state that upon 4xx in response to 
> > Expect: 100-Continue, the server should close the connection 
> > (after draining possibly pending data), just as it would do 
> > on a redirect to another domain for instance.
> >
> > That's an interesting case. I don't know how haproxy handles 
> > it, I suspect it could be tricky.
> 
> I think the current state is fine.  The current text says "If it responds
> with a final status code, it MAY close the transport connection or it MAY
> continue to read and discard the rest of the request."  Windows tries to
> leave the connection open (i.e. of course, upper layer can always override or
> we may have hit an non-continuable error such as corrupted request).  This
> allows the server to handle the following cases:
> 1) Client sent the entity-body before getting the expect-answer (e.g. timeout).
> 2) Client believes it is more efficient to send irrelevant entity-body
> instead of tearing down and warming up a new connection.
> 3) Client was sending a chunked entity-body and can gracefully indicate
> request end with a zero chunk.

But it does not cover the client which immediately receives the 417 and
which refrains from sending and instead reuses the connection.

It is all a matter of race condition : depending on the RTT between the
client and the server, the exact same sequence of operations at both sides
may lead to a different behaviour :
  - only headers are sent, client does not send body and goes on with next
    request ;
  - body starts to be sent and server has to drain it.

So the server cannot detect whether what follows is a body or a next
request.

I suspect that sending request-looking data in a POST with an Expect
header might produce interesting results which merit being studied on
various products :

   POST /public HTTP/1.1
   Host: www.example.com
   Expect: 100-Continue
   Content-Length: 100

   GET /private HTTP/1.1
   Host: www.example.com

In my opinion the only way to remain safe would be to systematically
close the connection after a 4xx. However it could cause problems with
connection-based authentication such as NTLM. It does not look like a
trivial problem.

Regards,
Willy

Received on Friday, 20 July 2012 06:03:26 UTC