Closed Bug 102312 Opened 23 years ago Closed 22 years ago

URL: Href attributes spanning multiple lines are taken to be relative rather than absolute links

Categories

(Core :: Networking, defect, P4)

defect

Tracking

()

VERIFIED FIXED
mozilla1.2alpha

People

(Reporter: emlyyn, Assigned: darin.moz)

References

Details

(Keywords: testcase, Whiteboard: DUPEME)

Attachments

(3 files)

There was a similar bug in the distant past: bug 57968 dealt in he fact that, if
a href attribute spanned multiple lines (<a href="http://ww
w.cat.org/">) that it would not link to the correct place.

Today, on my 2001 09 13 11 build, I see something similar but not identical -
although a link spanning multiple lines usually works, if the *protocol* part of
the link contains  a linebreak, then the whole link is treated as a relative
rather than absolute link. A link like "ht
tp://mozillazine.org/" on this page would not take you to everyone's favourite
newsrag, but rather to "http://bugzilla.mozilla.org/http://mozillazine.org/"
(not much to see there, though).

Expected behaviour: A protocol of "ht
tp://" should indicate to mozilla that this link is an absolute address rather
than a relative one.
Attached file Simplified Test Case
Confirmed using Mac/2001091311 (0.9.4). This is not an optimal resolution of this HREF 
URI. (Is some Quirks Mode nonsense to blame for this?)
Status: UNCONFIRMED → NEW
Ever confirmed: true
well, this bug is 4xp... and i probably attached that testcase to the wrong 
bug... is this parser?
Assignee: asa → pchen
Component: Browser-General → XP Apps
Keywords: 4xp
QA Contact: doronr → sairuh
->parser for triage
Assignee: pchen → harishd
Component: XP Apps → Parser
QA Contact: sairuh → moied
FWIW, the second URL of the testcase (with line-break) is equivalent to:
<ht tp://www.mozillazine.org/> (see bug 47078).  Our parsing may still not be
correct, however.
Parse does not handle attribute values other than attribute entities. The
problem must be in layout.
Assignee: harishd → attinasi
Component: Parser → Layout
QA Contact: moied → petersen
Target Milestone: --- → mozilla1.1
Mozilla no longer recognises "ht
tp" as even a link. Try context-clicking on the link in the testcase - can you
copy the link? Can you download it? No.
OS: Mac System 9.x → All
Hardware: Macintosh → All
->Networking for examination. I recently sent a similar bug for examination as
to why the weird relative URL behavior exists, but I can't find it to dupe.
Assignee: attinasi → darin
Component: Layout → Networking: HTTP
Keywords: testcase
QA Contact: petersen → tever
Whiteboard: DUPEME
-> URL parsing starts in Neworking (core).
Assignee: darin → new-network-bugs
Component: Networking: HTTP → Networking
QA Contact: tever → benc
Summary: Href attributes spanning multiple lines are taken to be relative rather than absolute links → URL: Href attributes spanning multiple lines are taken to be relative rather than absolute links
the problem is that we fail to parse the scheme from the URL since '\n' is not a
valid element of an URL scheme.  doh!  we should either strip newline characters
before parsing the scheme or ignore newline characters (since they are stripped
later on anyways).  this should be trivial to fix.
Assignee: new-network-bugs → darin
Severity: normal → minor
Priority: -- → P4
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
*** Bug 157987 has been marked as a duplicate of this bug. ***
This is is specified in the original URL RFCs 1680 and 1738.
Attached patch v1 patchSplinter Review
Add input filtering to nsStandardURL::Resolve matching the filtering that we
already do inside nsStandardURL::SetSpec.
Keywords: patch
Comment on attachment 95129 [details] [diff] [review]
v1 patch

r=dougt
Attachment #95129 - Flags: review+
Comment on attachment 95129 [details] [diff] [review]
v1 patch

sr=alecf
quick sanity check: I assume that FilterString does the handling of "\r\n\t"
cuz I don't see it in this patch - I assume buf is the scratch space that gets
assigned back to the return value of FilterString...
Attachment #95129 - Flags: superreview+
fixed-on-trunk
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Verified fixed.
Status: RESOLVED → VERIFIED
QA Contact: benc → junruh
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: