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

Status: RESOLVED FIXED

(Core :: XML, defect)

Description

[Bob Clary [:bc] (inactive)]

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.

Comment 1

[Bob Clary [:bc] (inactive)]

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

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I have no idea how content neg. could mess this up. Darin?

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

Content-Location: web-site-qa.xhtml
Server: Apache/1.3.27 (Unix) DAV/1.0.3 mod_gzip/1.3.26.1a mod_ssl/2.8.10
OpenSSL/0.9.6c PHP/4.2.3

"it was nice while it lasted"

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

[Bob Clary [:bc] (inactive)]

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

[Boris Zbarsky [:bzbarsky]]

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

[Hixie (not reading bugmail)]

My understanding is that our current behaviour is correct per specs, fwiw...

Comment 8

[Boris Zbarsky [:bzbarsky]]

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

[Hixie (not reading bugmail)]

Indeed.

Comment 10

[Bob Clary [:bc] (inactive)]

Fixed on 1.7 and trunk.