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
