Subject: Expect: 100-continue and proxies

From: Joe Orton <[email-masked]>
Date: Sun, 21 Feb 2010 11:03:45 +0000

2616 s8.2.3 first bullet of the requirements for proxies has a MUST 
requirement that a proxy forwards the Expect header to the next hop.

Apache httpd complies with this (whether by design or by accident, I'm 
not sure), though it makes little sense: the proxy is written to read 
and forward the entire request body without waiting for an interim 
response from the server.

Why is a MUST condition for the server to forward the 100-continue 
expectation appropriate, regardless of how a proxy handles the client's 
request body?

Regards, Joe

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 21 Feb 2010 19:28:30 +0000

> response from the server.

The proxy doesn't have to wait, because the client which sent Expect
will not send a request body for the proxy to forward, until the
timeout heuristic triggers.  There is no need for another delay from
the proxy.

> expectation appropriate, regardless of how a proxy handles the client's 

Because if it does not, there will be no 100 Continue sent to the
client, and the request body will be unnecessarily delayed.

-- Jamie

---

From: Joe Orton <[email-masked]>
Date: Mon, 22 Feb 2010 09:36:03 +0000

> timeout heuristic triggers.  There is no need for another delay from

Ah, I wasn't clear here: httpd/mod_proxy will, given a request 
containing "Expect: 100-continue":

1) send the request including the Expect header to the next hop
2) generate and send a "100 Continue" to the client
3) read the request body from the client and forward it to the next hop
4) read the response from the next hop and forward it to the client

So I guess this seems to comply with the letter of 2616 ("MUST forward 
the request, including the Expect header field") but not the spirit: 
that Expect is handled end-to-end, not hop-by-hop.

Regards, Joe

---

From: Jeffrey Mogul <[email-masked]>
Date: Mon, 22 Feb 2010 14:51:44 -0800

Just an FYI: before anyone fiddles with the Expect/Continue
mechanism, you should definitely read this paper:

  @INPROCEEDINGS{Bradley02safecomposition,
      author = {Adam D. Bradley and Azer Bestavros and Assaf J. Kfoury},
      title = {Safe Composition of Web Communication Protocols for Extensible
       Edge Services},
      booktitle = {In Workshop on Web Caching and Content Delivery (WCW},
      year = {2002}
  }

  Available via:
  http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.9.2854

The title is a bit of a red herring; the paper is mostly about
the specific case of the Expect/Continue mechanism.  In particular,
very subtle issues can create deadlocks when trying to interoperate
between proxies, clients, and servers implementing slightly different
versions of Expect/Continue.

I wouldn't expect the working group to use the same formal-verification
techniques that these authors used (not that it would be a bad idea
to do so, just that I don't think it will happen), but at least
people should try to understand the causes of the problems exposed
by this paper, before changing anything here.

-Jeff