- From: Jeffrey Mogul <Jeff.Mogul@hp.com>
- Date: Tue, 28 Jan 2003 11:14:03 -0800
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- cc: ietf-http-wg@w3.org
FYI, there was a paper at the 7th International Workshop on
Web Content Caching and Distribution (WCW) last year:
Adam D. Bradley, Azer Bestavros, Assaf J. Kfoury (Boston University)
"Safe Composition of Web Communication Protocols for Extensible Edge
Services"
http://2002.iwcw.org/papers/18500001.pdf
that's actually about how to formally check the interoperability
of different versions of the Expect/Continue mechanism. From
their abstract:
we show how ... a tool from the formal systems verification
community can be used to quickly identify problematic behaviors
of application-layer protocols with non-trivial communication
models such as HTTP with the addition of the 100 Continue
mechanism. As a case study, we examine several versions of the
specification for the Continue mechanism; our experiments
mechanically uncover multi-version interoperability problems,
including some which motivated revisions of HTTP/1.1 and some
which persist even in the current version of the protocol. We
develop relations for describing arbitrarily large compositions of
HTTP proxies using finite models, and also discuss the broader
applicability of these techniques to open internet protocol
development.
The lessons from this paper support Alex's belief that the only
two solutions to your problem are (1) avoid using Expect/Continue
if you want 100% reliable results, or (2) aggressively work to
get rid of non-RFC2616-compliant implementations.
My personal belief is that people who deployed RFC2068-compliant
implementations *in production use* were naive, stupid, or
obstructionist, and we should have zero sympathy for them. The
IETF process does insist on interoperability testing of Proposed
Standard specifications, and people who did *implement* RFC2068-
compliant systems deserve our gratitude, but the IETF (see
RFC2026) neither requires nor condones "deploying implementations
of [proposed] standards into a disruption-sensitive environment."
-Jeff
Received on Tuesday, 28 January 2003 14:14:05 UTC