Re: Removing Content-Location

tis 2007-03-06 klockan 16:18 +0100 skrev Julian Reschke:

> That would be 
> <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/thread.html#msg224>, 
> right? I wouldn't say it was rejected altogether, it's just that there 
> was no agreement that Content-Location can be removed completely.

Content-Location servers an important role in HTTP cache correctness and
Vary logics and can not be removed without significantly crippling the
specifications. But it's a optional header, and servers are free not to
send Content-Location if there is no suitable location to refer to of
the response entity or if they consider it unneeded.

Things like reverse proxies remapping the URL name space etc all has to
consider their effects on Content-Location, just as they need for
Location, Request-URI etc. By no means an impossible task, just an often
overlooked or forgotten task as most things tend to work anyway..

But I think everyone agreed that it's due to the large number of broken
servers out there isn't viable to implement two clauses relating to the
Content-Location header:

a) Future requests MAY specify the Content-Location URI as the request-
   URI if the desire is to identify the source of that particular
   entity.

and

b) The value of Content-Location also defines the base URI for the
   entity.


I am not entirely sure why these two criterias was added in RFC2616 (is
not in RFC2068 from what I can tell), but a guess is to align HTTP with
the related MHTML definitions of the same headers. But the definition in
RFC2616 does not conflict with RFC2068, only extends it's use. In both
specifications Content-Location 

In terms of specification they both makes sense. But the fact that none
of the major user-agents have implemented them for many years after and
that there is quite many deployed servers handling this wrongly does
speak for that these two clauses should perhaps be removed.

Regards
Henrik