241063 - URI Fragments are case sensitive

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[David McArthur]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

URI fragments (the part after the #) are matched on a case-sensitive basis. 
This is arguably correct, but different from how IE handles fragments resulting
in apparently broken links in pages designed and tested in IE.

This is closely related to bug 127373 and it's dependants.

Relavant standard would be RFC 2616
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.3

3.2.3 URI Comparison

When comparing two URIs to decide if they match or not, a client SHOULD use a
case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions:

      - A port that is empty or not given is equivalent to the default
        port for that URI-reference;

        - Comparisons of host names MUST be case-insensitive;

        - Comparisons of scheme names MUST be case-insensitive;

        - An empty abs_path is equivalent to an abs_path of "/".

Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396
[42]) are equivalent to their ""%" HEX HEX" encoding.

For example, the following three URIs are equivalent:

      http://abc.com:80/~smith/home.html
      http://ABC.com/%7Esmith/home.html
      http://ABC.com:/%7esmith/home.html


BUT, see the W3C's definitions of URI:
http://www.w3.org/Addressing/URL/4_2_Fragments.html
"This represents a part of, fragment of, or a sub-function within, an object .
Its syntax and semantics are defined by the application responsible for the
object, or the specification of the content type of the object. The only
definition here is of the allowed characters by which it may be represented in a
URL."

So perhaps it's up to browsers to determine how to interpret fragments in HTML
documents.

Reproducible: Always
Steps to Reproduce:
1. Find/make an HTML document with an <a name="Name">
2. Try to reference the document with a URI containing the fragment written all
lower-case

Actual Results:  
Document loads, but fails to jump down to fragment

Expected Results:  
IE finds the fragment using a case-insensitive search.  Lots of people develope
and test HTML using IE, so this appears to be something that "works" in IE but
"doesn't work" in Mozilla

Comment 1

[Darin Fisher]

If indeed valid, this would be a DOM bug.

Comment 2

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

> Relavant standard would be RFC 2616

no, since HTTP does never see fragment identifiers.

It is in fact HTML which is relevant, see:
http://www.w3.org/TR/html4/struct/links.html#h-12.2.1
An anchor name is the value of either the name or id attribute when used in the
context of anchors. Anchor names must observe the following rules:

    * Uniqueness: Anchor names must be unique within a document. Anchor names
that differ only in case may not appear in the same document.
    * String matching: Comparisons between fragment identifiers and anchor names
must be done by exact (case-sensitive) match.

hence, this bug is invalid.

Comment 3

[Josh Birnbaum]

*** Bug 293989 has been marked as a duplicate of this bug. ***

Comment 4

[Phil Ringnalda (:philor)]

*** Bug 329190 has been marked as a duplicate of this bug. ***

Comment 5

[Phil Ringnalda (:philor)]

*** Bug 332842 has been marked as a duplicate of this bug. ***

Comment 6

[Steve England [:stevee]]

*** Bug 363165 has been marked as a duplicate of this bug. ***