Deprecate Content-Location? (was RE: "Variant" language in Content-Location (Issue 109))

Julian Reschke wrote:
> So if I had to rewrite this I would make it just:
> 
>     The Content-Location entity-header field may be used to supply the
>     resource location for the entity enclosed in the message. 
>     In the case where a resource has multiple entities associated with 
>     it, and those entities actually have separate locations by which
>     they might be individually accessed, the server SHOULD provide a 
>     Content-Location for the particular variant which is returned.
> 
> (BCP14fying the should, dropping the last sentence)
> 
> Feedback appreciated,

1. The message might not contain an entity (e.g. if the request is a HEAD or
if the response code is 204 No Content), so "entity enclosed in the message"
is not really correct.

2. An entity is not the same thing as a variant, so you cannot substitute
"entity" for "variant". A variant is identified by (Resource-URI, Vary) or
(Resource-URI, Content-Location) and an entity is identified by
(Resource-URI, ETag) or (Resource-URI, Last-Modified, Content-Location). In
other words, there is a one-to-many relationship between variants and
entities (see the section that talks about invalidating cache entries based
on Content-Location).

3. The RFC 2616 language says that Content-Location SHOULD be provided in
every case. Your change only says Content-Location should be required in the
special case that begins "especially" in RFC 2616. So, it doesn't mean the
same thing.

4. There are important cases where the server SHOULD NOT include the
Content-Location header. In reality, a server can't safely include the
Content-Location header unless it knows that all relative URI references in
the entity representing the variant will resolve to the same URIs that they
would resolve to if the Content-Location was not provided (because almost
all clients ignore Content-Location when resolving relative URIs.)
Basically, it is only safe to send the Content-Location header in limited
circumstances. This is contradictory to the "server SHOULD provide a
Content-Location" advice.

5. What does "might be individually accessed" mean? As far as cache
validation is concerned (which is the only time Content-Location is used in
the protocol itself), the Content-Location doesn't have to be accessible.
That whole condition can be removed since it is meaningless.

- Brian

Received on Tuesday, 5 August 2008 23:33:59 UTC