W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: Deploying new expectation-extensions

From: Jamie Lokier <jamie@shareable.org>
Date: Fri, 4 Apr 2008 07:43:27 +0100
To: Adrien de Croy <adrien@qbik.com>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Mark Baker <distobj@acm.org>, HTTP Working Group <ietf-http-wg@w3.org>, google-gears-eng@googlegroups.com
Message-ID: <20080404064327.GA14657@shareable.org>

Adrien de Croy wrote:
> 1: where the extension was semantically incompatible with the current 
> version of HTTP. 
> 2: where the extension was optional in the current version but for some 
> reason indispensable to the client.
> Version changes I think is a better way to cope with the first class of 
> use-cases.

That's assuming agents reject a message with a newer version number...

Since they don't reject expectations, I would be surprised if they
consistently reject newer version numbers.

> There's no difference between a chain of 
> agent->intermediary->server supporting a newer version number than 
> supporting an extension.  It's just a matter of labelling.

Well, in principle you can try extensions privately ("Expect:
x-my-experiment") and they can be orthogonal.  Version numbering
forces linearity: if you handle feature Z, you must handle feature X
and Y too.

Also, agents tend to report they are HTTP/1.1 even when they are
grossly non-compliant.  I suspect that's due to it being a version to
aim for, and they do support some features of 1.1, and reporting the
version is advantageous.  If expectations were able to be used, naming
individual features, I suspect agents wouldn't pretend to handle all

In practice it seems there aren't that many "features" to be concerned

Peculiar things like chunked requests have long been unusable.... I
guess they might have fitted into the scheme.

-- Jamie
Received on Friday, 4 April 2008 06:44:07 UTC

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