Anchors in Content Negotiated Documents expose underlying file extension (Content-Location)




14 years ago
12 years ago


(Reporter: bc, Assigned: Heikki Toivonen (remove -bugzilla when emailing directly))




Firefox Tracking Flags

(Not tracked)





14 years ago
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.

Comment 1

14 years ago
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.
OS: Windows XP → All
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/ 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.
Blocks: 238654

Comment 5

14 years ago
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).
Summary: Anchors in Content Negotiated Documents expose underlying file extension → Anchors in Content Negotiated Documents expose underlying file extension (Content-Location)

Comment 10

14 years ago
Fixed on 1.7 and trunk.
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.