W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2004

Re: Can the response entity be transmitted before all the request entity has been read?

From: Jeffrey Mogul <Jeff.Mogul@hp.com>
Date: Mon, 15 Mar 2004 16:40:49 -0800
Message-Id: <200403160041.i2G0fELe018979@wera.hpl.hp.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:27 GMT