- From: Jeffrey Mogul <Jeff.Mogul@hp.com>
- Date: Mon, 15 Mar 2004 16:40:49 -0800
- To: Alex Rousskov <rousskov@measurement-factory.com>
- Cc: HTTP WG <ietf-http-wg@w3.org>
Moreover, there was a paper that formally proved that 100 Continue
leads to deadlocks in certain compliant environments, so we are
probably talking about a partially broken mechanism here anyway.
I believe Alex is referring to this paper:
"Safe Composition of Web Communication Protocols for
Extensible Edge Services"
Adam D. Bradley, Azer Bestavros, Assaf J. Kfoury (Boston University)
Proc. 7th Int' Workshop on Web Content Caching and Distribution (WCW)
http://2002.iwcw.org/papers/18500001.pdf
The title is a bit of a misdirection; it's not really about edge
services.
"The primary focus of this paper is on the applicability of formal
methods to the verification of the correctness and
interoperability of the HTTP protocol s revisions in all
per-mutations of roles (client, proxy, server) and compositions
thereof with respect to the 100 Continue feature.
Also, as I understand the paper, what they showed is that while
if everyone fully (and correctly) implemented the 100-Continue
specification of RFC2616, everything would be fine, we didn't
successfully design this feature to interoperate with RFC2068.
We also apparently said "MAY" instead of "MUST" in at least one
place, so partial (but legal) implementations of RFC2616 might
be a problem.
I suppose someone should take a look at the latest Internet-Draft
to see if it could be changed to avoid the last problem identified
in the paper. However, even this might be too late to make
"Expect: 100-continue" a safe thing for clients to send, unless we
change the protocol version number.
-Jeff
Received on Monday, 15 March 2004 19:41:20 UTC