nsStdUrl::Equals() uses strcasecmp to compare 2 urls. It is probably ok to do that for scheme, host, etc... But probably not for things like, query. This behavior makes Session History (which uses nsStdUrl::Equals()) to believe that 2 urls that are different only in the case sensitivity of the query are the same. To reproduce: 1. Go to the above url 2. Search for string addrequest. 3. After the results are displayed, click on the urlbar and change "addrequest" to "AddRequest", and press enter. 4. Click Back. Actual Result: -------------- You will be taken to http://lxr.mozilla.org/seamonkey Expected Result: ---------------- You should go to http://lxr.mozilla.org/seamonkey/search?string=addrequest If session History should be using some other method to verify equality of nsIURI objects, please update me. I will check it out.

cc'ing andreas... andreas: the case of the URL path should matter, right? that is, it's totally valid for a website to produce different results based on the case of the URL path, right? -> me

RFC 2396 says: 6. URI Normalization and Equivalence In many cases, different URI strings may actually identify the identical resource. For example, the host names used in URL are actually case insensitive, and the URL <http://www.XEROX.com> is equivalent to <http://www.xerox.com>. In general, the rules for equivalence and definition of a normal form, if any, are scheme dependent. When a scheme uses elements of the common syntax, it will also use the common syntax equivalence rules, namely that the scheme and hostname are case insensitive and a URL with an explicit ":port", where the port is the default for the scheme, is equivalent to one where the port is elided. So it seems URIs case sensivity depends on the scheme, with one exception: Scheme names consist of a sequence of characters beginning with a lower case letter and followed by any combination of lower case letters, digits, plus ("+"), period ("."), or hyphen ("-"). For resiliency, programs interpreting URI should treat upper case letters as equivalent to lower case in scheme names (e.g., allow "HTTP" as well as "http"). So it seems there is no real nice solution ... that is scheme independent.

well then, we could add a parameter to nsIStandardURL::Init that specifies (maybe with a mask type parameter) which fields in the URL can be considered case insensitive. then protocol handler impl's could properly configure nsStandardURL::Equals to do the right thing. sounds reasonable?

We could use the protocolFlags attribut from nsIProtocolHandler or something similar for that.

andreas: i don't think the flags need to be exposed to protocol hander clients. it's just a detail of the implementation, and since so many of our protocol handlers depend on nsStandardURL... they need a way to configure nsStandardURL to use case sensitive compares on certain portions of the URL.

Usually the protocol handlers have the code to create new urls, what better place to store protocol-dependend information? I don't know. Surely it's open to what extend this information should be exposed.

i think it best to wait until the 1.1 cycle to try to fix this. then we'll have plenty of time to flush out the regressions that will most likely fall out from this. -> 1.1

mass futuring of untargeted bugs

Fixed by checkin for bug 127373

V/fixed by depends.