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: Thu, 19 Jul 2012 00:09:10 +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: <20120718220910.GF11854@1wt.eu>
On Tue, Jul 17, 2012 at 10:32:58PM +0000, Osama Mazahir wrote:
> It's not broken as long as we are OK that the connection has to be closed
> upon expectation rejection (for non-chunked entity-body).
> 
> Based on my understanding, the client must close the connection if the server
> replied with a 4xx [1] against a non-chunked request.  Which makes sense as
> it ensures message integrity on a persistent connection [2].  Essentially, we
> break the ambiguity by having the server assume that the next byte (after the
> CRLFCRLF) will be entity-body.

You're right indeed, the protocol is broken in this case depending on whether
the client gets the 4xx in time and refrains from sending the body, or if it
starts sending the body before receiving the 4xx.

The protocol does not allow us to tell what the server will get depending on
the timing (either body or next request).

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.

Regards,
Willy
Received on Wednesday, 18 July 2012 22:10:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 18 July 2012 22:10:12 GMT