RE: NEW ISSUE: Drop Content-Location

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.

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. 

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

Received on Wednesday, 8 April 2009 03:21:42 UTC