RE: Clarifying Content-Location (Issue 136)

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

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.

Regards,
Brian

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