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

[Sjoerd Visscher]

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/

Re: xml:base in your Atom feed

[M. David Peterson]

 Hosting is not the point.Yep. 'tis why I said the word backup.On 3/31/06, A. Pagaltzis 
[EMAIL PROTECTED] wrote:
* M. David Peterson [EMAIL PROTECTED] [2006-04-01 03:15]: Obviously the main wiki would be better, but if this can act as a backup plan, then let me know if and when and I will set up
 access to that box for you.Hosting is not the point. I have webspace and I can link files Ihost from the main wiki, as before. Collaboration is the point.I'm hoping for a way for anyone to pitch in without having to
fight any red tape, so that the test suite can be expanded bywhoever happens to have a spare tuit.Regards,--Aristotle Pagaltzis // http://plasmasturm.org/
-- M:D/M. David Petersonhttp://www.xsltblog.com/ 

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

[James Holderness]

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