RE: Deprecate Content-Location? (was RE: "Variant" language in Content-Location (Issue 109))

Yves Lafon wrote:
> And also when you do a GET/HEAD on 
> http://www.exemple.org/foo/ (as you may want to edit the 
> "myniceindexpage.html" page :) ).

I understand that use case, but HTTP doesn't specify how that works at all.

> Well, it would be nice to have in the browser a way to figure 
> out that CL has been used, and wrongly or not (like CL: 
> http://internal:8080/...) so that site designers would have a 
> chance to get this right.
> 
> CL would be used to create latest/archived version of the 
> same content without having to rewrite all the internal 
> links, so it's a pity implementors (of both servers/reverse 
> proxies/browser) didn't got it right.

I agree that if it were actually implemented in an interoperable way, it
would be very useful. However, there is basically no interoperability for
the Content-Location header.

> CL _is_ useful (not for popular browsers, but those are not 
> the only UAs), so it would break things to remove it. It 
> seems that the best we can do is document that the state of 
> implementation is such that the only safe way to use CL is 
> when it resolves the relative links as the request URI...

In some cases, that means Content-Location can only be Request-URI (due to
links like "#fragment"). Anyway, I am not suggesting that Content-Location
be removed; that cannot be done. I am just suggesting that the advise in the
specification should change from encouraging its use to discouraging its
use.

> I read this as "at the time of the request, it was the URI 
> where "it might be ...", however nothing force the client to 
> access it there, nor the server to make it available. The 
> text looks fine as is, as it sets no condition on the implementation.

Like I said in the previous message, if it doesn't affect conformance then
it should be removed because it adds confusion. 

- Brian

Received on Wednesday, 6 August 2008 14:33:43 UTC