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: Wed, 29 Nov 2006 22:50:01 +0100
To: Anne van Kesteren <annevk@opera.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1164837001.15658.18.camel@henriknordstrom.net>
ons 2006-11-29 klockan 21:24 +0100 skrev Anne van Kesteren:
> It basically can't be implemented by web browsers. See for instance  
> https://bugzilla.mozilla.org/show_bug.cgi?id=109553 ... We've tried it as  
> well, broke the web, and then backed it out again.

Well.. partly because you want to support client side http-equiv parsing
at the same time I would suspect.. which isn't what http-equiv is meant
to be used for. These headers is meant to be processed on the server.
Allowing http-equiv to be parsed in the client is a mistake as it
creates a mismatch between the HTTP protocol and how the client behaves
creating an ever widening gap allowing HTTP misconfiguration to go
largely unnoticed. See the HTML specifications if in doubt.

It's not valid to have more than one Content-Location. Any response
having multiple Content-Location is on it's own wrt what the value of
Content-Location is understood to be.. It may be the first, last,
sequentially resolved (when relative URLs is used), or even the two
concatenated with a comma if something along the way chooses to merge
the headers..

Content-Location plays a fairly important role in caching invalidation
and also processing of Vary responses, and dropping it would
theoretically cripple the caching support in the HTTP protocol quite
noticeably even if very few caches currently implements it correctly..


Received on Wednesday, 29 November 2006 21:50:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2019 17:47:10 UTC