Content-Location issues (was RE: I-D ACTION:draft-nottingham-http-link-header-01.txt)

Henrik Nordstrom wrote:
> > I would like to see an "Edit" header that allows the server 
> > to say that PUT/DELETE requests should be sent to a different
> > request URI. For example, I want the server to suggest that
> > edit requests for the resource at http://example.org/foo 
> > should be sent to the authenticated URI 
> > https://example.org/foo).
> 
> This is one of the purposes of Content-Location, tells user agents the
> "original/primary" location of this object if it's accessed from a
> secondary location.

Here are the problems I found with using Content-Location for this:

* Content-Location changes the base URI used to resolve relative URIs. I
don't want to change the base URI for relative URIs because the https://
server has different authentication and caching policies from the http://
server. Plus, many clients get the base URI handling of Content-Location
wrong.

* Section 14.14 of RFC 2616 says "The Content-Location value is not a
replacement for the original requested URI; it is only a statement of the
location of the resource corresponding to this particular entity at the time
of the request. Future requests MAY specify the Content-Location URI as the
request-URI if the desire is to identify the source of that particular
entity." I want a header that says "Future requests, except for GET/HEAD
requests, SHOULD/MUST specify the <header-name> URI as the request-URI."
That is a small but very important difference.

* I want to provide an ETag for resource HTTPS://example.org/foo in the
response to a request at HTTP://example.org/foo, so that I can immediately
issue meaningful conditional requests at the HTTPS:// URI. I think it would
make sense for the specification to say that, when a response has an ETag
field and a Content-Location field, the ETag MAY be used for meaningful
conditional requests at the Content-Location URI. But, RFC 2616 doesn't say
that.

Recently I've seen a few discussions regarding Content-Location, where the
definition of Content-Location *almost* seems to do what people want. For
example:

* Julian Reschke's GET-Location header [1]. Roy Fielding and others have
said that Content-Location does the same thing as the proposed
Content-Location header, but after reading RFC 2616 very carefully, I don't
think the current definition of Content-Location is clear enough to draw
that conclusion. 

* If a response to a PUT contains a Content-Location header and/or
Expires/Cache-Control headers and/or an ETag, can we cache that response (to
the PUT) for subsequent GET requests to the Content-Location URI. In
particular, can we do so when the Request-URI is the same as the
Content-Location URI? See [2]. My reading of RFC 2616 is that it explicitly
says we can't do that. However, I'm not sure why not; it seems perfectly
sensible do so, as long as the security considerations are kept in mind.

It would be nice if the specification clearly explained the relationship
between a response with a Content-Location of "X" and requests with a
Request-URI of "X".

[1]
http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html
[2] http://www.imc.org/atom-protocol/mail-archive/msg10845.html (Be sure to
read the whole thread)

Regards,
Brian

> It's not pushed very hard in the specs as there is nothing 
> that says the
> two really has any strict relation to each other. The one giving you
> Content-Location may well be lying about it and providing you an
> entirely different object than what is available at the 
> Content-Location
> specified URI, just as they may make up any other headers 
> such as Link..
> 
> Regards
> Henrik
> 
>

Received on Wednesday, 30 April 2008 01:40:57 UTC