RE: Clarifying Content-Location (Issue 136)

Julian Reschke wrote:
> Brian Smith wrote:
> > 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)

Exactly. Content-Location doesn't have any interoperable uses in HTTP. My
point is that Content-Location is generally safe only when Content-Location
= Request-URI, but then it is useless, except for its misuse in AtomPub (See
RFC 5023 to see how Content-Location is used in AtomPub).

> The use is to identify a specific variant.

It doesn't identify a specific variant, because the resource at the
Content-Location may also be subject to content negotiation (especially
Vary: Content-Encoding). 

Secondly, why SHOULD servers identify every variant with a URL? I agree that
they MAY do so, but why SHOULD? Especially, if a resource varies only on
Content-Encoding, why SHOULD a server provide three URLs for it? Besides the
base URI issue, it reduces cache efficiency if anybody actually requests the
resource through the Content-Location URLs. It also complicates the
management of the URL space on the server. Yet, there's no benefit to be
gained from the added costs.

Regards,
Brian

Received on Monday, 28 September 2009 06:59:47 UTC