13311 - nsStdUrl parsing broken when / after # or ?

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Heikki Toivonen (remove -bugzilla when emailing directly)]

If you have an URL like http://some.domain.com/foo#/1/2 this breaks the parser.
Similarly http://some.domain.com/foo?/1/2 will break as well.

If you are wondering were these kinds of constructs might come up, check the
990709 draft of XPointer (http://www.w3.org/TR/WD-xptr). Below is a monster URL
that is a valid URL + XPointer but will choke the parser:

http://me.com/foo#xptr(id("ref37")/ancestor::*/attribute::lang[position()=last()
]/string::3,"Thomas Pynchon",8)

I have made an XPointer component but I cannot use it because of this...

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Partial fix, href="#/1/2" and "?/1/2"

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

The patch (id=1616) fixes relative URLs that start with # or ?. The case with #
is a bit strange - in the course of creating this there are times when wrong
data members are filled with wrong values, but eventually the correct URL is
created.

This fix does not fix absolute nor relative URLs that do not begin with # or ?.

After lookin at the Parse() method I would be more than willing to pass this to
the person who wrote Parse() in the first place...

Comment 3

[Andreas Otte]

I have a fix for this, waiting for review ...

Comment 4

[Andreas Otte]

fix checked in ...

Comment 5

[Gagan]

thanks Andreas.

Comment 6

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Verified these in debugger, nsStdURL:GetSpec() with following URLs:

target.html?/1/3#/5/6
target.html?/1/3#/5/6/slot('?#/')
target.html?/1/3#/5/6/slot('\?#/')

All the member variables seem to hold correct values.