Subject: Re: Does xml:base apply to type="html" content?

From: Sjoerd Visscher <[email-masked]>
Date: Sat, 01 Apr 2006 11:33:10 +0200

> I also understand there is some debate whether supporting 
> Content-Location is a good idea at all (at least in web browsers). 
> Firefox at one point started adding support, but they determined that it 
> caused problems with broken servers (mostly IIS I believe). 

As far as I, support for Content-Location was reverted because in 
Firefox same-document references are broken when used with some sort of 
base URI. I.e. if you have a document with <a href="#x"> with 
Content-Location: http://y/z, Firefox will go to the anchor named x in 
the document at http://y/z, instead of to the anchor named x in the 
current document.

-- 
Sjoerd Visscher
http://w3future.com/weblog/

---

From: "James Holderness" <[email-masked]>
Date: Sat, 1 Apr 2006 17:12:15 +0200

Sjoerd Visscher wrote:
> As far as I, support for Content-Location was reverted because in Firefox 
> same-document references are broken when used with some sort of base URI. 
> I.e. if you have a document with <a href="#x"> with Content-Location: 
> http://y/z, Firefox will go to the anchor named x in the document at 
> http://y/z, instead of to the anchor named x in the current document.

That's not quite the way I understood it. The bug that ended it all can be 
seen here:
https://bugzilla.mozilla.org/show_bug.cgi?id=241981

I think comment #5 sums it up best. Basically fragement links on a 
content-negotiated page would expose (via the Content-Location support) the 
URI of the actual page rather than the original neutral URI. This becomes an 
issue when you start bookmarking such links and sending them to your friends 
whose browsers don't necessarily support the same content types as yours.

As for the other issues with Content-Location and broken servers, you can 
see most of the details here:
https://bugzilla.mozilla.org/show_bug.cgi?id=109553

It appears to be mostly problems with Microsoft and Oracle servers. The 
solution at the time was to keep adding those servers to a blacklist (I died 
a little inside when I read that). Ultimately that became unnecessary when 
they backed out the fix.

I think the issue of neutral link bookmarking is unlikely to be a problem 
for Atom aggregators though. Server bugs are another thing, but I think most 
feeds will be broken without an explicit xml:base anyway, so maybe that's 
not worth worrying about. I'm not sure though. Should the WG recommend 
ignoring Content-Location as a base URI, or should aggregators follow the 
RFC exactly as specified?

Regards
James Holderness

---

From: Anne van Kesteren <[email-masked]>
Date: Sun, 02 Apr 2006 10:49:19 +0200

Quoting James Holderness <[email-masked]>:
> I think the issue of neutral link bookmarking is unlikely to be a 
> problem for Atom aggregators though. Server bugs are another thing, 
> but I think most feeds will be broken without an explicit xml:base 
> anyway, so maybe that's not worth worrying about. I'm not sure 
> though. Should the WG recommend ignoring Content-Location as a base 
> URI, or should aggregators follow the RFC exactly as specified?

If `Content-Location` is not usable or can't be used consistent on a website
(for example, using it for both Atom and HTML content) I suggest we specify
something that is consistent with what browsers do. And perhaps try to 
obsolete
the relevant header if possible...

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

---

From: "James Holderness" <[email-masked]>
Date: Tue, 4 Apr 2006 03:15:09 +0200

Anne van Kesteren wrote:
> obsolete the relevant header if possible...

Isn't this something the HTTP WG should be doing? If they have plans to 
obsolete the header then I think it makes sense for us to discourage its 
use, but so far I've seen nothing suggesting they're even contemplating 
that.

The way I see it, until a standards body tells us otherwise, we are obliged 
to support the Content-Location header unless we can provide a very good 
argument for ignoring it. The Firefox developers may well have done that for 
web browsers, but I'm not yet convinced that their issues are necessarily 
applicable to aggregators.

Regards
James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 4 Apr 2006 04:09:19 +0200

* James Holderness <[email-masked]> [2006-04-04 03:25]:
> The way I see it, until a standards body tells us otherwise, we
> are obliged to support the Content-Location header unless we
> can provide a very good argument for ignoring it.

+1, standards aren’t there for people to cherry-pick the parts
they find convenient or useful.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 04 Apr 2006 12:17:07 +0200

Quoting James Holderness <[email-masked]>:
>> something that is consistent with what browsers do. And perhaps try 
>> to obsolete the relevant header if possible...
>
> Isn't this something the HTTP WG should be doing?

I guess so. The HTML WG (W3C, same concept) should be doing a lot of things as
well. That doesn't mean it actually happens...

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 04 Apr 2006 12:15:54 +0200

> they find convenient or useful.

If interoperable implementations for standards are not possible, they are
useless. The goal of having standards is interoperable implementations. Opera
has removed support for Content-Location (or least partially, not sure of the
details) for the same reasons as Firefox.

(This also isn't really about convenient or useful...)

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 4 Apr 2006 13:06:00 +0200

* Anne van Kesteren <[email-masked]> [2006-04-04 12:20]:
> If interoperable implementations for standards are not
> possible, they are useless. The goal of having standards is
> interoperable implementations. Opera has removed support for
> Content-Location (or least partially, not sure of the details)
> for the same reasons as Firefox.
> 

Yes. I considered adding a long diatribe about standards, but
decided against it. In short, I know that standards are not an
end in themselves and that is not what I’m trying to say. Interop
is always the end goal; and that’s exactly why it’s as important
not to cherry-pick standards as it is to not follow them blindly.
It’s a tight-rope walk. Departure from a standard is necessary
sometimes but must be well considered implentor consensus,
otherwise you might as well have no standards at all. And if that
becomes best practice, it should be codified (that is the right
way to write standards, after all).

Etc etc. Let’s not go into all this; it should be clear.

I’m not principally opposed to opposition to `Content-Location`;
it just seems like a precarious proposition to have specs start
to arbitrarily limit the applicability of select other specs.
That way lies spec interaction madness in unforeseen scenarios.
If there is a real problem, the appropriate reaction needs to
become established best practice outside of specs and then should
be codified in the appropriate upstream spec. Let’s not willfully
make things even more complicated than they already are.

Regards,

---

From: Sjoerd Visscher <[email-masked]>
Date: Tue, 04 Apr 2006 22:37:33 +0200

Anne van Kesteren wrote:
>> anyway, so maybe that's not worth worrying about. I'm not sure though. 
>> Should the WG recommend ignoring Content-Location as a base URI, or 
>> should aggregators follow the RFC exactly as specified?
> 

The problem is not with Content-Location, but with RFC 3986. It says 
that same-document references must be resolved with respect to the base 
URI. It adds that when those references are resolved, they should not 
result in a new retrieval action, but that does not help with things 
like bookmarking (as James pointed out), and is almost impossible to 
implement.

---

From: Martin Duerst <[email-masked]>
Date: Wed, 05 Apr 2006 12:20:55 +0900

>> Isn't this something the HTTP WG should be doing?

Just for the record, there is currently no HTTP WG. The mailing
list of the former HTTP WG still exists. As this was an IETF WG,
and is an IETF mailing list (hosted by W3C), you can easily join
and bring this issue up. Here's the necessary data:

List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Subscribe: <mailto:[email-masked]?subject=subscribe>
Resent-Message-Id: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]?subject=unsubscribe>
Resent-Message-Id: <[email-masked]>

Regards,    Martin.