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

RE: Clarifying Content-Location (Issue 136)

From: Brian Smith <brian@briansmith.org>
Date: Sun, 27 Sep 2009 22:54:48 -0500
To: "'Julian Reschke'" <julian.reschke@gmx.de>, "'Robert Brewer'" <fumanchu@aminus.org>
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <000901ca3fef$71650560$542f1020$@org>
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.

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

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.

Received on Monday, 28 September 2009 03:55:33 UTC

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