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

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

The rule to use there is if there is more than one Request-URI which can
be used to access the resource. If there is only a single Request-URI
which can be used for requesting that resource (or variant thereof if
the resource is varying) then Content-Location is meaningless.


> > 4. There are important cases where the server SHOULD NOT include the
> > Content-Location header. In reality, a server can't safely include the
> 
> That sounds like a separate and new issue.

Not really new.. see earlier discussions about deprecating
Content-Location, they all circulate around this 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?

The point of Content-Location is to provide THE unique URI on which this
specific resource (variant) can be accessed. The cache invalidation
rules is a deduction from this fact, and so is the use of
Content-Location as a variant identifier.

Servers giving Content-Location URIs which isn't accessible is clearly
not doing the right thing. 

Servers not wanting to provide unique URIs for variants of a the
resource at the request-URI or transformed request-URIs should not sent
Content-Location.

What I mean by transformed request-URI is when the actual resource-URI
is different from request-URI. I.e. if there is "/index.html.gz" on the
server and all (or at least more than one) of "/" "/index", "/index/",
"/index.html", "/index.gz" and "/index.html.gz" can be used as
request-URI when requesting this resource.

Note: ETag serves the job of being an identifier with no URI
implications. There is absolutely no point in degrading the
identification properties of Content-Location to that of ETag.

Regards
Henrik

Received on Thursday, 7 August 2008 13:23:53 UTC