What explains the use of Firefox and Safari for various custom URIs containing more than one # character? Which one is right?

Question

In Firefox 4.0.1, paste the following line into the address bar

http://www.w3.org/#one#two 

Note that the browser goes to the first page of w3.org and the address bar is still reading

 http://www.w3.org/#one#two 

In Safari 5.0.4 do the same. Please note that the browser also performs navigation, but the text of the address bar changes to read

 http://www.w3.org/#one%23two 

Please note that the first hash of the hash in the line does not change, and the second changes to the encoded form (the so-called "escaped")% 23.

It seems reasonable to assume that Safari is trying to convert the user-provided URI into a link that matches its idea of ​​a valid URI. In this case, Firefox does not do the conversion.

I would like to explain the difference in behavior.

The document at http://www.ecma-international.org/publications/standards/Ecma-262.htm is one reference to what form a valid URI takes. Section 15.1.3.1 states that browsers do not store URIs.

The "#" character is not decoded from escape sequences, even if it is not a reserved URI character.

What this implies is that it refers to the # characters in the URI string, not just the first occurrence.

In conclusion, my question is:

• Do both forms of reference comply with the latest standard for valid URIs?
• If they are both valid, which browser behavior is most suitable?

Answer 1

RfC 3986 (determining which URIs and therefore URLs look and what the parts mean) does not allow two # characters in one URL, at least in my reading. This makes the question boil down to the following:

• Is it better to forward a custom error to a web application (where the designer could have made the same error),
• or is it better to convert user input into something closely related but real?

Also note that RfC clearly displays # as a reserved character, so the ECMA standard is wrong in what you indicated above.