Closed Bug 13311 Opened 25 years ago Closed 25 years ago

nsStdUrl parsing broken when / after # or ?

Categories

(Core :: Networking, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: hjtoi-bugzilla, Assigned: gagan)

References

Details

Attachments

(1 file)

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...
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...
Target Milestone: M14
Blocks: 13449
I have a fix for this, waiting for review ...
fix checked in ...
QA Contact: paulmac → tever
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
thanks Andreas.
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: