- From: Yves Lafon <ylafon@w3.org>
- Date: Wed, 14 Oct 2009 08:48:12 -0400 (EDT)
- To: Julian Reschke <julian.reschke@gmx.de>
- cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>, Roy Fielding <fielding@gbiv.com>
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.
> 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."
Looks good.
--
Baroula que barouleras, au tiéu toujou t'entourneras.
~~Yves
Received on Wednesday, 14 October 2009 12:48:15 UTC