Last Comment Bug 241981 - Anchors in Content Negotiated Documents expose underlying file extension (Content-Location)
: Anchors in Content Negotiated Documents expose underlying file extension (Con...
: regression
Product: Core
Classification: Components
Component: XML (show other bugs)
: Trunk
: x86 All
-- major (vote)
: ---
Assigned To: Heikki Toivonen (remove -bugzilla when emailing directly)
: Ashish Bhatt
: Andrew Overholt [:overholt]
Depends on:
Blocks: 238654
  Show dependency treegraph
Reported: 2004-04-28 10:06 PDT by Bob Clary [:bc:]
Modified: 2006-03-12 17:30 PST (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Bob Clary [:bc:] 2004-04-28 10:06:31 PDT
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 User image Bob Clary [:bc:] 2004-04-28 10:15:48 PDT
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.
Comment 2 User image Heikki Toivonen (remove -bugzilla when emailing directly) 2004-04-28 14:34:26 PDT
I have no idea how content neg. could mess this up. Darin?
Comment 3 User image Christian :Biesinger (don't email me, ping me on IRC) 2004-04-28 14:42:17 PDT
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"
Comment 4 User image Boris Zbarsky [:bz] (still a bit busy) 2004-04-28 14:52:29 PDT
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.
Comment 5 User image Bob Clary [:bc:] 2004-04-28 14:58:14 PDT
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.
Comment 6 User image Boris Zbarsky [:bz] (still a bit busy) 2004-04-28 15:04:22 PDT
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....
Comment 7 User image Hixie (not reading bugmail) 2004-04-28 15:30:38 PDT
My understanding is that our current behaviour is correct per specs, fwiw...
Comment 8 User image Boris Zbarsky [:bz] (still a bit busy) 2004-04-28 15:33:41 PDT
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).
Comment 9 User image Hixie (not reading bugmail) 2004-04-28 15:37:01 PDT
Comment 10 User image Bob Clary [:bc:] 2004-04-30 11:14:49 PDT
Fixed on 1.7 and trunk.

Note You need to log in before you can comment on or make changes to this bug.