- 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