- 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 UTC