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
In Mozilla 1.6 you will go to
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
I have no idea how content neg. could mess this up. Darin?
Server: Apache/1.3.27 (Unix) DAV/1.0.3 mod_gzip/188.8.131.52a mod_ssl/2.8.10
"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.