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

Re: Expect: 100-continue and proxies

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Fri, 14 May 2010 13:02:32 +0200
To: Joe Orton <joe@manyfish.co.uk>
Cc: ietf-http-wg@w3.org
Message-Id: <1273834952.10328.30.camel@localhost.localdomain>
fre 2010-05-14 klockan 11:11 +0100 skrev Joe Orton:

> I can't find that explicit requirement in 2616; am I missing it, or 
> should it simply be implied from the MUST requirement to forward Expect?

It's implied form

- Only mention of 100 in relation to proxies is MUST forward, except
when it MUST NOT or MAY NOT forward.

- The only entity mentioned in creating 100 responses is explicitly
origin servers which either MUST, MUST NOT or MAY generate 100 responses
depending on the conditions, not servers in general.

Plus the general function of Expect + 417, See below.

The main reason why proxies should not normally generate 100 responses
is the same reason why 100 responses were added, the need of providing a
clean forwarding path where the client knows the server is willing to
accept the request without obvious waste of network resources should the
server (or proxy) want to reject the request. A proxy responding with
100 Continue breaks this as it does not yet know the request body can or
should be forwarded. And if you apply this recursively in a chain of
proxies then the breakage becomes more apparent.

The proxy MAY however add Expect: 100-continue provided it's then
prepared to deal with 417 responses without bothering the client, but
doing so is not trivial as it requires storing a copy of the request
until a response of some kind is seen, allowing the proxy to reforward
the request without Expect: 100-continue should a 417 response be seen.

For similar reasons proxies MUST NOT respond with synthesized 100
Continue responses to Expect: 100 Continue, as this breaks any handling
of 417 responses to the Expect. It's not valid to send or forward 417
after sending 100 Continue. So if a proxy synthesizes 100 Continue in
response to Expect: 100-continue it must also save a copy of the request
data until a response is seen and then reforward without Expect:
100-continue if a 417 is seen, BUT this is incompatible with the
requirement that proxies MUST forward Expect headers which leaves the
proxy in the unfortunate situation that it should not forward the 417
and MUST NOT reforward the request without Expect..

All in all, attempting to deal with adding 100 Continue or
adding/removing Expect: 100-continue in a proxy is a complex matter with
quite subtle cases you have to deal with to not break the protocol
expectations of the requesting client. The only case where it's
reasonably safe is after a considerable delay in response to 2068
requests without Expect: 100-continue. And then only to work around old
clients who don't implement Expect: 100-continue and which also do not
implement a timer themselves when seeing that the proxy is HTTP/1.1.

Proxies MAY however drop 100 responses if either the request was without
Expect: 100-continue or of the client have already started to send the
request body. This is a harmless optimization of the protocol.

Received on Friday, 14 May 2010 11:03:43 UTC

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