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

On Wed, 6 Aug 2008, Brian Smith wrote:

>> So do you think that servers SHOULD return a Content-Location
>> even when only one entity is associated?
>
> IF Content-Location is going to live on then I agree that the RFC 2068-like
> definition makes more sense. Basically that if the response contains a Vary
> header then the entity should have a Content-Location header.

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

>>> 4. There are important cases where the server SHOULD NOT
>>> include the Content-Location header. In reality, a server
>>> can't safely include the Content-Location header unless it
>>> knows that all relative URI references in the entity
>>> representing the variant will resolve to the same URIs
>>> that they would resolve to if the Content-Location was not
>>> provided (because almost all clients ignore Content-Location when
>>> resolving relative URIs.) Basically, it is only safe to send the
>>> Content-Location header in limited circumstances. This is
>>> contradictory to the "server SHOULD provide a
>>> Content-Location" advice.

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 am not sure that Content-Location can even be defined in a useful way due
> to this problem. The reason I bring it up here is that "Servers SHOULD NOT
> include a Content-Location header in the response entity" reflects the lack
> of support for Content-Location in most clients, but that is the opposite of
> your suggested change.

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

> If the "might be individually accessed" condition is important then it needs
> to be clarified so that implementations know what they are supposed to do to
> meet the condition. But, I don't think the condition adds any value which is
> why I suggest that it is simply removed.

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.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Wednesday, 6 August 2008 13:46:16 UTC