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

Re: expect header, clarification of status

From: Jeffrey Mogul <Jeff.Mogul@hp.com>
Date: Tue, 28 Jan 2003 11:14:03 -0800
Message-Id: <200301281914.h0SJE3qR032104@wera.hpl.hp.com>
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

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

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."

Received on Tuesday, 28 January 2003 14:14:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:36 UTC