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

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

That's true (and the same text is in 2616). Care to propose something else?

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

The current plan for Issue 109 is to get rid of the term "variant", and 
to make "representation" and "entity" equivalent 
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/109>). There's a 
*separate* issue for "requested variant", which is issue 69 
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/69>).

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

Yes, that's intentional and reflects what RFC 2068 said. I think the 
change in RFC 2616 was incorrect (overzealous conversion to BCP 14 
keywords).

So do you think that servers SHOULD return a Content-Location even when 
only one entity is associated?

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

That sounds like a separate and new issue.

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

What's the point in supplying a Content-Location, if nobody can access it?


BR, Julian

Received on Wednesday, 6 August 2008 07:56:03 UTC