Subject: Re: NEW ISSUE: Drop Content-Location [#154]

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Oct 2009 15:23:08 +1100

I haven't seen any discussion of this, but I believe the general  
feeling is to drop the base-setting semantics of Content-Location in  
HTTP.

Any other thoughts? Otherwise we'll go in that direction.

On 07/04/2009, at 1:53 PM, Mark Nottingham wrote:

> 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
>
>
> On 07/04/2009, at 12:52 PM, Ian Hickson wrote:
>
>> On Tue, 7 Apr 2009, Mark Nottingham wrote:
>>>
>>> Anne and Ian, does this adequately encompass your issue? If other
>>> aspects are important, it would be helpful if you provided a  
>>> succinct
>>> summary.
>>
>> 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.   `._.-(,_..'-- 
>> (,_..'`-.;.'
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Oct 2009 15:31:52 +0200

Mark Nottingham wrote:
> I haven't seen any discussion of this, but I believe the general feeling 
> is to drop the base-setting semantics of Content-Location in HTTP.
> 

+1, but we need to consider the details.

Currently, we have

"The value of Content-Location also defines the base URI for the entity."

Do we drop this (potentially breaking currently conforming 
implementations), or do we make it optional?

In both case, we'll also have to record this as a normative change in 
the Changes section.

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Oct 2009 09:39:09 +1100

On 08/10/2009, at 12:31 AM, Julian Reschke wrote:

>> feeling is to drop the base-setting semantics of Content-Location  
>> in HTTP.

Personally, I'd say the former; we've found cases where it can be  
harmful, it isn't widely implemented, and making it optional will lead  
to yet more interoperability problems. We are chartered to improve  
interop, and are explicitly allowed to change things when this is the  
case.

> In both case, we'll also have to record this as a normative change  
> in the Changes section.

Yes.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 08 Oct 2009 12:08:08 +0200

Mark Nottingham wrote:
> interop, and are explicitly allowed to change things when this is the case.
> 

OK, change applied with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/712> (which has 
broken checkin comment, sorry for that).

I note that in <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154>, 
we have:

> Note that this differs from the MIME header of same name. 

Is this something that requires spec text, or was that just a reminder 
that HTTP and MIME are allowed to differ with respect to this?

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Oct 2009 14:14:09 +1100

On 08/10/2009, at 9:08 PM, Julian Reschke wrote:
>
> OK, change applied with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/712 
> > (which has broken checkin comment, sorry for that).

Closing issue. Julian, at some point it would probably be good to  
update the change note to reflect that this wasn't done just because  
of poor implementation take-up; the reason behind that was that using  
C-L for base caused problems with conneg and other situations (IIRC).

> I note that in <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/ 
> 154>, we have:
>
> Is this something that requires spec text, or was that just a  
> reminder that HTTP and MIME are allowed to differ with respect to  
> this?

Don't think it requires any spec text; that wasn't part of the on-list  
discussion.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Oct 2009 10:59:48 +0200

Mark Nottingham wrote:
> ...
> Closing issue. Julian, at some point it would probably be good to update 
> the change note to reflect that this wasn't done just because of poor 
> implementation take-up; the reason behind that was that using C-L for 
> base caused problems with conneg and other situations (IIRC).
> ...

I'll happily do that, if somebody could remind what these problems 
are/were...

BR, Julian

---

From: Yves Lafon <[email-masked]>
Date: Wed, 14 Oct 2009 05:40:46 -0400 (EDT)

On Wed, 14 Oct 2009, Julian Reschke wrote:

>> implementation take-up; the reason behind that was that using C-L for base 
>> caused problems with conneg and other situations (IIRC).
>> ...
>

Well, the main issue is lack of implementation on client side, bad CL 
headers sent by servers especially when servers are behind a front-end. 
(like CL: http://10.1.2.80:8080/foo ), making it hard to rely on in the 
general case.

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

         ~~Yves

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Oct 2009 20:41:48 +1100

Wasn't there also some aspect whereby a negotiated resource would make  
the links relative to the C-L URL, thereby messing things up?

On 14/10/2009, at 8:40 PM, Yves Lafon wrote:

>>> update the change note to reflect that this wasn't done just  
>>> because of poor implementation take-up; the reason behind that was  
>>> that using C-L for base caused problems with conneg and other  
>>> situations (IIRC).
>>> ...
>>
> Well, the main issue is lack of implementation on client side, bad  
> CL headers sent by servers especially when servers are behind a  
> front-end. (like CL: http://10.1.2.80:8080/foo ), making it hard to  
> rely on in the general case.
>
> --

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Oct 2009 11:55:55 +0200

> (like CL: http://10.1.2.80:8080/foo ), making it hard to rely on in the 

Yes, that's the reason that's already listed: UAs did not implement it 
(so servers got away with sending broken headers, and now the UA 
implementers say they can't fix it anymore).

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Oct 2009 12:02:03 +0200

> the links relative to the C-L URL, thereby messing things up?

Ah, that part.

So the issue is: the C-L *does* set the base URI, it may break relative 
links when original URI and CL-URI use different paths (well, unless the 
format allows setting the base URI in-line as well, for instance in HTML 
using the <base> element).

So how about changing:

"Remove base URI setting semantics for Content-Location due to poor 
implementation support."

to

"Remove base URI setting semantics for Content-Location due to poor 
implementation support, which was caused by too many broken servers 
emitting bogus Content-Location headers, and also the potentially 
undesirable effect of potentially breaking relative links in 
content-negotiated resources."

?

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Oct 2009 21:49:12 +1100

Works for me.

On 14/10/2009, at 9:02 PM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> Wasn't there also some aspect whereby a negotiated resource would  
>> make the links relative to the C-L URL, thereby messing things up?
>> ...
>
> Ah, that part.
>
> So the issue is: the C-L *does* set the base URI, it may break  
> relative links when original URI and CL-URI use different paths  
> (well, unless the format allows setting the base URI in-line as  
> well, for instance in HTML using the <base> element).
>
> So how about changing:
>
> undesirable effect of potentially breaking relative links in content- 
> negotiated resources."
>
> ?
>
> BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Oct 2009 13:30:16 +0200

> Works for me.

OK, in <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/714>.

BR, Julian

---

From: Yves Lafon <[email-masked]>
Date: Wed, 14 Oct 2009 08:48:12 -0400 (EDT)

On Wed, 14 Oct 2009, Julian Reschke wrote:

> Mark Nottingham wrote:
>> Wasn't there also some aspect whereby a negotiated resource would make the 
>> links relative to the C-L URL, thereby messing things up?
>> ...
>
> Ah, that part.
>
> So the issue is: the C-L *does* set the base URI, it may break relative links 
> when original URI and CL-URI use different paths (well, unless the format 
> allows setting the base URI in-line as well, for instance in HTML using the 
> <base> element).

Well, it's the same issue really, this time due only to bad client side 
support of CL that led to issue with conneg+CL when one client happens to 
support CL.

> implementation support, which was caused by too many broken servers emitting 
> bogus Content-Location headers, and also the potentially undesirable effect 
> of potentially breaking relative links in content-negotiated resources."

Looks good.

         ~~Yves