656853 - The URI "file://" doesn't handle hash references correctly

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Daniel Holbert [:dholbert]]

I've been writing an extensive xpcshell test for parsing references from URIs/URLs for bug 308590, and I've discovered that the URI "file://" doesn't handle references correctly.

In particular, if I do (e.g. in xpcshell):
> js> var foo = NetUtil.newURI("file://#myRef")   
> js> foo.spec
> file:///

(I'd expect the above to say "file:///#myRef". Note that the parser inserts an extra "/" for the path, which is fine, but I'd hope that it'd preserve the #myRef, too.)

For comparison, here's the result with http:
> js> var foo = NetUtil.newURI("http://#myRef")
> js> foo.spec
> http:///#myRef
(note that here, too, the parser inserts an extra "/", but in this case it preserves the #myRef.)

Comment 1

[Daniel Holbert [:dholbert]]

Note that the issue goes away if my input has 3 slashes instead of 2 -- e.g.:
> js> var foo = NetUtil.newURI("file:///#myRef")    // note the triple-slash!
> js> foo.spec
> file:///#myRef
          ^yay!

Given that file:// and file:/// end up parsing to the same URI, I'd expect that I'd be able to append a reference to both of those input strings, and still produce equal URIs.

(This holds for "http://" and "http:///", for example -- appending #myRef to each of those produces URIs that are equal to each other.)

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Patch to fix this and update tests (assumes patch for bug 622981 is applied)

Comment 3

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 545156 [details] [diff] [review]
Patch to fix this and update tests (assumes patch for bug 622981 is applied)

r=me

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Checked in: http://hg.mozilla.org/mozilla-central/rev/26c113f4780a