- 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
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
features.
In practice it seems there aren't that many "features" to be concerned
about.
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