- 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