W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: p2: Requirements upon proxies for Expect

From: Willy Tarreau <w@1wt.eu>
Date: Sat, 20 Apr 2013 11:18:51 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <20130420091851.GS26517@1wt.eu>
On Sat, Apr 20, 2013 at 07:00:19PM +1000, Mark Nottingham wrote:
> p2 5.1.1 "Requirements for HTP/1.1 proxies" bullet one effectively requires
> proxies to forward ALL requests with Expect: 100-continue if the inbound
> server is HTTP/1.1 -- even if the request is a GET.
> I know that this isn't the intent, but that's how it reads; suggest
> qualifying this to only apply to requests with bodies.

Do you see any risk in applying this to any request ? I've been thinking
in the past about the possibility to use Expect to send non-idempotent
requests over existing connections without fearing the risk of a broken
connection, but the stupid situation where a client sends an empty POST
with Expect is still problematic. All this to say that there might be
some usages of Expect that are not covered here and not problematic

> The next bullet requires proxies to respond with a 417 if the inbound server
> is HTTP/1.0. Just curious here - why? Wouldn't the maximally interoperable
> thing be to generate a 100-continue yourself? While the client *could*
> resubmit the request, they probably won't, because as far as they know, the
> origin told them not to.

That's exactly what I thought as well when reading this point ! And FWIW,
haproxy does so when it needs to parse part of the request body to pick
a server. I think that was the exact intended purpose of skipping as
many "100" responses as needed BTW.

Received on Saturday, 20 April 2013 09:19:35 UTC

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