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

On tis, 2008-04-29 at 18:40 -0700, Brian Smith wrote:
> 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.

that is a slight difference.

>  Plus, many clients get the base URI handling of Content-Location
> wrong.

True. and as many servers get Content-Location wrong user-agent authors
do not want to implement this proper..

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

There is no chance to get this specified as a SHOULD/MUST as you still
need to be compatible with eralier clients..

And no matter what you do you will still be battling the same security
issues which holds Content-Location back. See below.

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

You may, but there is nothing in HTTP which says that a response from
URI A is authorative for URI B. Content-Location is just a hint, and if
you trust the server and ETag matches it's a fairly good one (about as
good as you can get within HTTP).

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

It's as close as you can get. But that discussion is a bit muddled up
from the fact that WebDAV doesn't map very well to the HTTP object
model.

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

If a response to PUT has a cache validator you can use that to verify
that there has not been any other edits of the object, but it's not a
guarantee that the resource held by the server matches the entity you
sent in PUT.

> In
> particular, can we do so when the Request-URI is the same as the
> Content-Location URI?

Yes. Or when the two differ. No difference really. But you can not
assume the PUT request entity as authorative for the current state of
the indicated server resource. The only thing you can take as
authorative is the ETag value.

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

If you request "X" you are supposed to get the same result as you
earlier got with a Content-Location: X, but security concerns says there
is no guarantee this is the case and trivial to fake in many situations
so they MUST NOT be automatically considered equal.

The exact same security concern applies to any Link type header you can
come up with as it's not about the header content or syntax but about
who is authorative for the object at "X".

Because of these concerns the spefications degrade Content-Location a
bit, making it less useful than intended. Perhaps too much but it's
easier to fix those cases than trying to invent a new header for the
same thing and go over the same security concerns and loopholes again.

Regards
Henrik

Received on Wednesday, 30 April 2008 02:02:45 UTC