W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: Clarifying Content-Location (Issue 136)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 28 Sep 2009 08:29:33 +0200
Message-ID: <4AC057CD.3060201@gmx.de>
To: Brian Smith <brian@briansmith.org>
CC: 'Robert Brewer' <fumanchu@aminus.org>, 'HTTP Working Group' <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:51 UTC