W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

Re: NEW ISSUE: Drop Content-Location

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 29 Nov 2006 23:30:06 +0100
Message-ID: <456E09EE.3010404@gmx.de>
To: Anne van Kesteren <annevk@opera.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>

Anne van Kesteren schrieb:
> On Wed, 29 Nov 2006 22:40:25 +0100, Julian Reschke 
> <julian.reschke@gmx.de> wrote:
>> From what I see the problem was that many deployed servers return a 
>> Content-Location header containing a URI which in fact isn't 
>> accessible from the outside. That's a server bug.
> 
> I'm sure you read 
> https://bugzilla.mozilla.org/show_bug.cgi?id=109553#c37 as well which 
> suggests otherwise. Also, whether it's servers or clients that are 
> broken doesn't really matter. The simple fact is that the header can't 
> be supported.

Actually, the interesting information seems to be in 
<https://bugzilla.mozilla.org/show_bug.cgi?id=238654>.

I'm very nervous, because other specs, such as RFC2518 (out since 1999) 
and APP (new) use Content-Location, so I really don't see how it can be 
dropped.

>> The header allows relative URIs, so it seems to me it would be safe 
>> for user agents to support the header if - for instance - it's an 
>> absolute path. That should still cover the majority of the use cases...
> 
>  From my recollection we can't really implement it in any way.

It's late, any I may not have seen all the cases of breakage, but most 
of them seem to involve private IPs and bogus port numbers. Both 
problems will not occur when an absolute path is used.

Best regards, Julian
Received on Wednesday, 29 November 2006 22:30:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:53 GMT