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

Henrik Nordstrom wrote:
> Brian Smith wrote:
> > In some cases, that means Content-Location can only be Request-URI 
> > (due to links like "#fragment"). Anyway, I am not suggesting that 
> > Content-Location be removed; that cannot be done. I am just 
> > suggesting that the advise in the specification should change
> > from encouraging its use to discouraging its use.
> 
> Why?
> 
> Deprecating the Base-URI part is one thing, but whats wrong 
> with the rest?

The Base-URI part is the main problem. Even if that is overcome, the
security implications are another major problem.

> I still do not get what the fuzz is about here. The 
> definition of Content-Location is very clear when placed in 
> the content model HTTP is defined for.
> 
> I'd say the real issue probably is that 2616 isn't very clear 
> on the content model. There is related RFCs documenting the 
> content model of HTTP is documented correctly, unfortunately 
> it's number escapes me at the moment..

Is it RFC 2295 (http://tools.ietf.org/html/rfc2295)?

In my proposed rewrite of the Content-Location definition, I wrote 'Previous
versions of this specification recommended the use of Content-Location to
identify the individual "variants" of a resource. Applications MAY continue
to do so, but the details of this usage are undefined by this specification
(just as they were left undefined in previous versions).' I wrote it that
way for two reasons:

(1) The current proposal for i109 loses the distinction between variants and
entities, but the RFC 2616 definition of Content-Location needs to have that
distinction in order to make sense (because Content-Location identifies a
variant, not an entity). My use of quotes on "variants" is intended to
indicate that the term doesn't have a useful definition (in HTTPbis or RFC
2616).

(2) Like you said, RFC 2616 is unclear about the content model. The
impression I got is that HTTPbis is going to leave the content model
undefined (up to the application) as in RFC 2616. From that, it follows that
any meaning of Content-Location that relies on the content model is going to
be undefined, and so any usage of Content-Location beyond defining the base
URI is also undefined. My statement "but the details of this usage are
undefined..." is just makes that clear in the specification. If HTTPbis is
going to define the content model then the last paragraph of my proposal
would need to be rewritten; in that case, it would be better for defer any
changes to the definition of Content-Location until after the content model
work is done.

> > Like I said in the previous message, if it doesn't affect 
> > conformance then it should be removed because it adds
> > confusion.
> 
> Understanding the intended content model of HTTP affects 
> conformance as it's very easy to get things like ETag, 
> Content-Location, variant, cache, Vary, and even Request-URI 
> wrong without being interpreted in that context.

I agree. But, if there is a content model that all applications are supposed
to follow then the specification should define that model. If there is no
agreed-upon definition of what "accessible at that location" means then
effectively it is meaningless; if there is an agreed-upon definition of
"accessible at that location" then why shouldn't that definition be part of
the specification? 

> The Content-Location text is only a little muddled because of 
> potential security implications if used wrongly ...

The security problem is a big deal.

> ... but it's 
> intended meaning is very clear from the text. And I also 
> argue that it's intended use is equally clear including how 
> to transition from a GET of a Request-URI directly to a 
> conditional PUT to Content-Location for authoring that 
> specific variant.

In general, you cannot transition from a GET on one request-URI directly to
a conditional PUT on another URI, regardless of Content-Location, because
you cannot use the ETag from the GET response in the If-Match header of the
PUT (well, you can, but doing so is meaningless). This is stated pretty
clearly in section 3.11 of RFC 2616: "The use of the same entity tag value
in conjunction with entities obtained by requests on different URIs does not
imply the equivalence of those entities." Instead, you have to do a GET on
the Content-Location URI to get the ETag (you cannot use HEAD), and then do
the conditional PUT using the ETag from the second GET. And, besides that,
the security issues get in the way.

- Brian

Received on Sunday, 10 August 2008 23:02:11 UTC