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 ) 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
If indeed valid, this would be a DOM bug.
Assignee: darin → general
Component: Networking → DOM: HTML
QA Contact: benc → ian
> 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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
*** Bug 293989 has been marked as a duplicate of this bug. ***
*** Bug 329190 has been marked as a duplicate of this bug. ***
*** Bug 332842 has been marked as a duplicate of this bug. ***
*** Bug 363165 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.