W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

Re: NEW ISSUE: Drop Content-Location

From: Henrik Nordstrom <hno@squid-cache.org>
Date: Thu, 30 Nov 2006 04:11:30 +0100
To: Mark Baker <distobj@acm.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1164856290.820.51.camel@henriknordstrom.net>
ons 2006-11-29 klockan 21:33 -0500 skrev Mark Baker:

> Sure, but there are limits to HTTP extensibility.  One limit is that
> you can't introduce extensions which change the meaning of the message
> such that existing agents would interpret it incorrectly.
> Content-Base is such an extension, hence the need for the version rev
> to protect those agents.

Bumping the version won't protect those agents. Version numbers is
mainly a compliance specification thing.

A change which would make existing servers or clients non-compliant with
the specifications need a version bump, but still requires careful
thought on interoperability as the version number is not useful at the
protocol level, only compliance specification level.

An related example. For interoperability with HTTP/1.0, servers should
not assume Content-Location is universally understood and should allow
URLs to be resolved reasonably (but maybe not optimal) even if
Content-Location is ignored. This even if the request received is
HTTP/1.1 as that only indicates the compliance level of the last hop,
not the compliance level of the actual user-agent.

But to be honest I don't see how adding yet another header solves any of
the problem. There will again most certainly be plenty of servers
deployed not sending this new header correct, and adding the new header
does not solve the reasons why servers has problems sending correct
Content-Location headers.  Only hope says that client deployment of this
new feature will be sufficiently quick to bring awareness of the feature
before too many servers gets it wrong again, and to me that's not a good
reason for a specification change.

Regards
Henrik

Received on Thursday, 30 November 2006 03:11:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:53 GMT