Subject: Re: NEW ISSUE: Drop Content-Location

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Apr 2009 12:37:45 +1000

It's not helpful to formulate the issue as 'Drop Content-Location';  
ATM, my inclination is to create it as 'Content-Location base-setting  
problems'.

Anne and Ian, does this adequately encompass your issue? If other  
aspects are important, it would be helpful if you provided a succinct  
summary.

I'm not sure we yet have consensus, but I'm optimistic that we're  
close. Roy made two proposals:

> The only thing that should be changed at this point is 14.14:
>
>   The value of Content-Location also defines the base URI for the
>   entity.
>
> s/also defines/does not define/;

> I would prefer to say
> that a recipient may disregard the base-setting semantics if there  
> also
> exists a base URI from the retrieval context and use of that base URI
> for parsing relative references within the entity results in fewer
> errors than use of the Content-Location URI.  A bad Content-Location
> value SHOULD be reported to the user as an error.

Roy, which do you prefer, and does anyone else have a preference?

Furthermore, would it be useful if we gave advice about generating  
relative Content-Locations, to avoid at least some of the errors  
described in this thread?

On 31/03/2009, at 12:24 AM, Julian Reschke wrote:

> The mail below (<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0254.html 
> >) seems to be the last in this thread, and seems to reflect the  
> consensus we reached.
>
> Should we record this as an issue then (it wasn't before), and  
> implement this change?
>
> BR, Julian
>
> Roy T. Fielding wrote:
>> On Dec 4, 2006, at 11:09 AM, Mark Nottingham wrote:
>>> HTTP headers have a separate name space in the message header  
>>> registry, so it can be done;
>>>  http://www.iana.org/assignments/message-headers/perm-headers.html
>> That's a nice theory, but HTTP carries MIME messages and they are  
>> actually
>> the same fields in one namespace. Conflicts are noticed by the  
>> folks who
>> are responsible for maintaining MIME and they do, historically,  
>> object to
>> the IESG when HTTP attempts to reuse them in a way that might lead to
>> confusion if a message passes across protocol boundaries.
>> At most, what we could do is say that a recipient may ignore the
>> base-setting semantics of Content-Location when present in the
>> outermost fields of an HTTP message received during HTTP  
>> communication.
>> Personally, I think that would be a mistake.  I would prefer to say
>> that a recipient may disregard the base-setting semantics if there  
>> also
>> exists a base URI from the retrieval context and use of that base URI
>> for parsing relative references within the entity results in fewer
>> errors than use of the Content-Location URI.  A bad Content-Location
>> value SHOULD be reported to the user as an error.
>> ....Roy
>
>
>

--
Mark Nottingham     http://www.mnot.net/

---

From: Ian Hickson <[email-masked]>
Date: Tue, 7 Apr 2009 02:52:31 +0000 (UTC)

> aspects are important, it would be helpful if you provided a succinct 

IIRC, browsers have found it impossible to implement Content-Location as 
setting the base URI for a document without breaking significant content 
on the Web. So long as what HTTP defines is implementable in a manner that 
is compatible with legacy content, the issue would be resolved, I think. 
IMHO it is not critical whether this is done by making the header have no 
effect, have some other effect, or removing the header altogether (though 
the former seems pointless).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: David Morris <[email-masked]>
Date: Mon, 6 Apr 2009 20:15:30 -0700 (PDT)

On Tue, 7 Apr 2009, Mark Nottingham wrote:

> It's not helpful to formulate the issue as 'Drop Content-Location'; ATM, my 
> inclination is to create it as 'Content-Location base-setting problems'.
>
> Anne and Ian, does this adequately encompass your issue? If other aspects are 
> important, it would be helpful if you provided a succinct summary.
>
> I'm not sure we yet have consensus, but I'm optimistic that we're close. Roy 
> made two proposals:
>
>> that a recipient may disregard the base-setting semantics if there also

I prefer a third choice ...
  ... a recipient SHOULD disregard the base-setting semantics if there
      also exists a base URI from the retrieval context.

I don't like the 'fewer errors' rule as that suggests the recipient is
expected to try both and make a judgement.

Also, I see no point in reporting a bad Content-Location to the user.
I still hold the belief that here should be an error report method which
clients may use to report errors to the origin server. The origin is
the responsible party with the potential to care. But that concept
was shot down years ago.

Also, reporting a bad value anywhere implies that the recipient must
evaluate the value...

Dave Morris

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Apr 2009 13:53:55 +1000

OK. As mentioned, C-L does other things besides set the base, so it  
seems like we just need to choose between the two proposals from Roy  
(or come up with another).

Now issue #154;
   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Apr 2009 14:15:08 +1000

If I understand correctly, neither weighing the errors nor allowing in- 
content base to have precedence will help.

Consider the content negotiation case (which AIUI is the most evident  
problem, from the browser vendor standpoint); if response is  
negotiated, it may or may not have an embedded base; if it doesn't,  
the error will still be evident.

Likewise, if go the 'least errors' path (and I share your discomfort  
here), a browser will need to actually dereference URLs to figure out  
what base to use, which is hardly practical (and even then, it may not  
be able to judge what qualifies as an error; is it just a 404, or  
something more subtle?).

As such, personally I think Roy's first proposed solution -- getting  
rid of the base-setting semantics of Content-Location -- is the only  
viable path.

On 07/04/2009, at 1:15 PM, David Morris wrote:

>> ATM, my inclination is to create it as 'Content-Location base- 
>> setting problems'.
>>
>> aspects are important, it would be helpful if you provided a  
>> succinct summary.
>>

---

From: Yves Lafon <[email-masked]>
Date: Tue, 7 Apr 2009 03:33:31 -0400 (EDT)

On Tue, 7 Apr 2009, Mark Nottingham wrote:

> If I understand correctly, neither weighing the errors nor allowing 
> in-content base to have precedence will help.
>
> problem, from the browser vendor standpoint); if response is negotiated, it 
> may or may not have an embedded base; if it doesn't, the error will still be 
> evident.

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.

So getting rid of CL is not an option, unless you are a pure browser. 
Removing the base setting property of CL is one option, it would be 
against rfc2257, but at least it will be consistent with most of the 
errors in server configurations that led with the behaviour of browser.

> As such, personally I think Roy's first proposed solution -- getting rid of 
> the base-setting semantics of Content-Location -- is the only viable path.
>
>
>
>>> It's not helpful to formulate the issue as 'Drop Content-Location'; ATM, 
>>> my inclination is to create it as 'Content-Location base-setting 
>>> problems'.
>>> 
>>> Anne and Ian, does this adequately encompass your issue? If other aspects 
>>> are important, it would be helpful if you provided a succinct summary.
>>> 
>>> I'm not sure we yet have consensus, but I'm optimistic that we're close. 
>>> Roy made two proposals:
>>> 

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

         ~~Yves

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 07 Apr 2009 11:07:31 +0200

> aspects are important, it would be helpful if you provided a succinct  

That sounds fine.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 7 Apr 2009 22:21:06 -0500

Yves Lafon wrote:
> 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

---

From: Yves Lafon <[email-masked]>
Date: Wed, 8 Apr 2009 03:28:46 -0400 (EDT)

> the base URI, and (2) identifying a variant for the purposes of cache

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.

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

         ~~Yves

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 8 Apr 2009 09:00:23 -0500

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

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.

>     entity is accessible from a location separate from the requested

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. 

> correctly implementing CL, but unfortunately, unless web developpers
> have access to tools that would point them to their mistakes in the

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