- 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.. Regards Henrik
Received on Wednesday, 29 November 2006 21:50:36 UTC