684993 - ioService URL parse problem

Status: UNCONFIRMED

(Core :: XPCOM, defect)

Description

[passfree]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.865.0 Safari/535.2

Steps to reproduce:

The following should throw but it doesn't:

ioService.newURI('http://./', null, null).QueryInterface(CI.nsIURL)

If a developer relies on this method to validate a URL, this potentially could lead to other types of bugs.

Comment 1

[Boris Zbarsky [:bzbarsky]]

newURI does all kinds of invalid-url fixup, so if you're using it to _validate_ URLs, you've already lost.

Comment 2

[passfree]

Then 

https://developer.mozilla.org/en/nsIURI
https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIURL

Is totally wrong.

The documentation reads...

"""
Subclasses of nsIURI, such as nsIURL , impose further structure on the URI.
"""

Then

"""
You can get a nsIURL from a nsIURI, using the QueryInterface method:
"""

And there is even an example:

"""
var myURI = Components.classes["@mozilla.org/network/io-service;1"]
                      .getService(Components.interfaces.nsIIOService)
                      .newURI("http://developer.mozilla.org", null, null);
try {
  var myURL = myURI.QueryInterface(Components.interfaces.nsIURL);
}
catch(e) {
  // the URI is not an URL
}
"""

I don't mind if the ioService cannot parse URLs correctly but we need to make sure that this is the same message delivered in the documentation. :)

Comment 3

[Boris Zbarsky [:bzbarsky]]

The documentation is completely correct.  It's talking about the objects (e.g. an nsIURL has a filename and a path, whereas a typical nsIURI might well not have those).

IOService parses urls the way they need to be parsed on the web.  If you want non-web URL parsing, you'll probably need to roll your own.

Comment 4

[passfree]

Imho this is a bit misleading. If nsIURL is only used to cast nsIURI to URLs, i.e. add more fields to the object, then the documentation should not recommend this as a method for validating urls. Therefore the example in the MDC should be removed to avoid further confusion.

As I said I am not trying to solve my own bug :) but I thought to report it since it doesn't make sense to me.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Where does the documentation mention "validating"?

The example doesn't say anything about validating, either.  You may be misunderstanding what "not a URL" means there; it just means "not an instance of nsIURL"...  Would that wording change make it clearer?

I'm happy to clarify the documentation, but I really don't see how you got validation out of it to start with....

Comment 6

[passfree]

Well the comment say that "URI is not a valid URL". From a person who has no idea what is going on underneath the ioService this is misleading. By reading the documentation my understandings are that the ioService can parse any URI. If I try to Query for the nsURL I will get a URL. If the URL is not valid an exception will be thrown.

Btw, incase you missed the point I am trying to make...

http://./

...is not a valid url. This is also not a valid url:

http://:/

but the ioService is happy to accept both. Both may look fine from URI point of view but make no sense as URLs.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> Well the comment say that "URI is not a valid URL".

No, that's in fact _not_ what it says.  What it says is what you said in comment 2 and very much does not use the word "valid".

> By reading the documentation my understandings are that the ioService can parse any
> URI.

Not at all.  It'll try to parse the string you give it as a URI, including some fixup, and then if that fails it will throw.

> If I try to Query for the nsURL I will get a URL.

If the URI is for a hierarchical scheme.  Otherwise it will throw.

I have no idea how you're defining "URL" in comment 6, but those are strings that need to be parsable into http: nsIURI objects for web compat.  And any http: nsIURI implements nsIURL.