Re: Clarifying Content-Location (Issue 136)

Brian Smith wrote:
> Julian Reschke wrote:
>> Robert Brewer wrote:
>>>   The "Content-Location" entity-header field supplies a URI for the
>>>   entity in the message when it is different than the requested
>>>   resource's URI. When a resource has multiple entities accessible
>>>   at separate locations, a server SHOULD provide a Content-Location
>>>   for the variant.
>> Yes, that's better. How about changing the end to
>>    ...SHOULD provide a Content-Location for the returned entity.
> First, "when it is different than the request resource's URI" is unnecessary
> and wrong. Having a Content-Location that is the same as the request URI is
> valid and is actually the only safe use of Content-Location.

What use would that be? (assuming we're talking about GET)

> Since the use of Content-Location for cache invalidation was recently
> removed, there are now NO interoperable uses for Content-Location. So, why
> SHOULD the server provide a Content-Location? I would say that the server
> really, really SHOULD NOT provide a Content-Location unless it knows that
> there are no relative URLs in the resource or in any headers in the
> response. Also, other protocols (e.g. AtomPub) overload Content-Location for
> other purposes which further reduces the cases where Content-Location is
> appropriate.

The use is to identify a specific variant.

The base-URI question has a separate issue 

> It would be better for interoperability to say "Servers SHOULD NOT use the
> Content-Location header." At the very least, the specification must not say
> that servers "SHOULD" use the Content-Location header.
> ...

I think that's a separate discussion (and I happen to disagree).

BR, Julian

Received on Monday, 28 September 2009 06:30:17 UTC