The url is on an Apache server with content negotiation enabled. Visit the above page and hover or click on the links to the named anchors in the table of contents. For example, click on the "Mozilla and Web Site Testing" link In Mozilla 1.7 and Trunk from 2004-04-27 on WinXp you will go to http://bclary.com/2004/04/10/web-site-qa.xhtml#intro In Mozilla 1.6 you will go to http://bclary.com/2004/04/10/web-site-qa#intro The fact that the underlying extension is exposed makes Mozilla unusable for content negotiation sites.
Confirm same behavior in Linux 20040421 1.7 build. Note also that MSIE and Opera do not expose the extension although they get the html version rather than the xhtml version.
I have no idea how content neg. could mess this up. Darin?
Content-Location: web-site-qa.xhtml Server: Apache/1.3.27 (Unix) DAV/1.0.3 mod_gzip/22.214.171.124a mod_ssl/2.8.10 OpenSSL/0.9.6c PHP/4.2.3 "it was nice while it lasted"
Why is this a problem? The underlying extension being exposed is precisely the one we negotiated with the server.... Unless we're talking about issues with moving this URL outside Mozilla? Perhaps we should have a nice long conversation with Apache about what this header means. Clearly, they're not interpreting it the way we are.
The communication with someone using something other than Mozilla is the issue in my opinion. For example, I use Mozilla and send the target of the link to someone who uses MSIE. Mozilla can handle XHTML fine, but MSIE will hork when it sees it. Or perhaps I change the implementation of that document later and there is no longer an actual file with .xhtml extension. Losing the extension neutrality of content negotiated links is bad I think.
Hmm... So really, the problem is that resolution of fragment identifiers uses the base URI, not the document URI? This is a problem for fragment identifiers in general, mind you, not just for Content-Location but also for <base href>. Darin, thoughts? Since fragment identifiers are not, strictly speaking, part of the URI, what should we be doing? We've had similar issues with not being able to use fragment identifiers on pages where the document URI is something like wyciwyg, by the way....
My understanding is that our current behaviour is correct per specs, fwiw...
Ian, that doesn't help, since the HTTP/1.1 RFC actively encourages this header to be sent with content-negotiated content the way Apache does. If all of our behavior is correct, the only option I see is to back out support for content-location (perhaps leaving a comment explaining that no one should ever try implementing it because it is broken-by-design).
Fixed on 1.7 and trunk.