Re: Clarifying Content-Location (Issue 136)

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

Actually, we just recently clarified the spec, supporting what AtomPub 
does. See <http://tools.ietf.org/wg/httpbis/trac/ticket/110>. The 
description of Content-Location probably should mention that other section.

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

OK, it defines a resource which may or may not have a one-to-one 
relation to a variant.

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

That's a good point, in particular because of Content-Encoding. I 
propose that we discuss this as a separate issue (Mark, are you ok with 
opening a separate one for this?)

BR, Julian

Received on Monday, 28 September 2009 07:27:26 UTC