- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 29 Nov 2006 23:30:06 +0100
- 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 UTC