RE: NEW ISSUE: Drop Content-Location

On Tue, 7 Apr 2009, Brian Smith wrote:

> Yves Lafon wrote:
>> There is a difference between a browser and an editor there. Browsers
>> already chose to not implement CL at all because of errors in some
>> server configurations (mostly reverse proxies, but not only). For
>> editors it is quite different, as finding the document really
>> served is needed when you want to save it back.
>
> 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.

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

> Some implementations *do* correctly implement RFC 2616 and use
> Content-Location as the base URI. Popular web browsers don't, but lots of
> web service clients do. Retaining Content-Location in but removing the base
> URI semantics in HTTPbis would result in these being noncompliant with
> HTTPbis because they implemented RFC 2616 correctly. It also means that
> clients could not be simultaneously compliant with RFC 2616 and HTTPbis.

Most of the CL I found will set a base that is in fact the base defined by 
the request URI, but of course there are counter-examples, like 
http://jigsaw.w3.org/HTTP/CL/
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.

> Deprecating Content-Location is the only reasonable way to resolve the
> situation. Servers MUST NOT send it, but if they do send it, then clients
> must be allowed to interpret it according to the RFC 2616 semantics.
>
> - Brian
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Wednesday, 8 April 2009 07:28:55 UTC