W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 06 Aug 2008 09:55:18 +0200
Message-ID: <489958E6.8090707@gmx.de>
To: Brian Smith <brian@briansmith.org>
CC: 'HTTP Working Group' <ietf-http-wg@w3.org>

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 

> 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 

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:37 UTC