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: Willy Tarreau <w@1wt.eu>
Date: Fri, 20 Jul 2012 08:02:38 +0200
To: Osama Mazahir <OSAMAM@microsoft.com>
Cc: Roberto Peon <grmocg@gmail.com>, Julian Reschke <julian.reschke@gmx.de>, 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>
Message-ID: <20120720060238.GE20313@1wt.eu>
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

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.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:04 UTC