RE: NEW ISSUE: Drop Content-Location

Yves Lafon wrote:
> On Tue, 7 Apr 2009, Brian Smith wrote:
> > Content-Location doesn't define the URI that is to be used for
> > editing the document. Editors that use it for that are making
> > a mistake. Consider the case where Content-Location is not a
> > http:// URI (e.g. Content-Location: urn:foo:bar) and it will
> > be obvious. There needs to be some way to identify
> > the URI to use for editing a resource, but overloading Content-
> > Location for that is a bad idea considering its serious problems.
> > There are also serious security issues with using
> > Content-Location as the editing URI.
> >
> > The only real semantics that RFC 2616 gives Content-Location are (1)
> > setting the base URI, and (2) identifying a variant for the purposes
> > of cache invalidation.
> 
> Editors can do a HEAD or a GET on the resource identified by the CL to
> ensure that they are editing the right content, and it's more or less
> mandatory when you are editing resources that are using conneg.

Doing a GET/HEAD on the CL resource doesn't solve the security problem. It
is basically the same issue as we have for redirects, where a client is
forbidden from following certain redirects automatically.

> <<<
>     The Content-Location entity-header field MAY be used to supply the
>     resource location for the entity enclosed in the message when that
>     entity is accessible from a location separate from the requested
>     resource's URI.
> >>>

It doesn't say that editing the resource at the Content-Location will cause
a change in the variant of the original resource with that Content-Location
value. RFC 2616 also doesn't define any way of editing an individual variant
of a resource or even mention if it is possible or not. 
The way resources relate to each other is not specified by HTTP but instead
by the applications of HTTP, like WebDAV and AtomPub. 

> So yes, it would be against MIME, and against all the UA that are
> correctly implementing CL, but unfortunately, unless web developpers
> have access to tools that would point them to their mistakes in the
> configuration of their system, there is no real solution to this issue.

Right, that is why we should drop Content-Location. There is no practical
way to make it work as it is defined in RFC 2616 and HTTPbis shouldn't say
"uh, do the opposite of what RFC 2616 says". If an application doesn't like
the RFC 2616 semantics for Content-Location then it just needs to avoid
using Content-Location and its problem is solved. Is there any application
where that solution doesn't work, besides ones that overloaded
Content-Location with meanings that the specification never gave it?

Regards,
Brian

Received on Wednesday, 8 April 2009 14:00:59 UTC