95705 - nsStdUrl::Equals() uses strcasecmp for "Get" queries

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Radha on family leave (not reading bugmail)]

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.

Comment 1

[Darin Fisher]

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

Comment 2

[Andreas Otte]

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.

Comment 3

[Darin Fisher]

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?

Comment 4

[Andreas Otte]

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

Comment 5

[Darin Fisher]

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.

Comment 6

[Andreas Otte]

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.

Comment 7

[Darin Fisher]

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

Comment 8

[Darin Fisher]

mass futuring of untargeted bugs

Comment 9

[Boris Zbarsky [:bzbarsky]]

Fixed by checkin for bug 127373

Comment 10

[benc]

V/fixed by depends.