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)
Core
Networking
Tracking
()
VERIFIED
FIXED
mozilla1.2alpha
People
(Reporter: emlyyn, Assigned: darin.moz)
References
Details
(Keywords: testcase, Whiteboard: DUPEME)
Attachments
(3 files)
325 bytes,
text/html
|
Details | |
81 bytes,
text/html
|
Details | |
647 bytes,
patch
|
dougt
:
review+
alecf
:
superreview+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•23 years ago
|
||
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?
Comment 5•23 years ago
|
||
->parser for triage
Assignee: pchen → harishd
Component: XP Apps → Parser
QA Contact: sairuh → moied
Comment 6•23 years ago
|
||
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
Updated•23 years ago
|
Target Milestone: --- → mozilla1.1
Reporter | ||
Comment 8•22 years ago
|
||
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
Comment 9•22 years ago
|
||
->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
Comment 10•22 years ago
|
||
-> 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
Assignee | ||
Comment 11•22 years ago
|
||
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
Assignee | ||
Comment 12•22 years ago
|
||
*** Bug 157987 has been marked as a duplicate of this bug. ***
Comment 13•22 years ago
|
||
This is is specified in the original URL RFCs 1680 and 1738.
Assignee | ||
Comment 14•22 years ago
|
||
Add input filtering to nsStandardURL::Resolve matching the filtering that we already do inside nsStandardURL::SetSpec.
Comment 15•22 years ago
|
||
Comment on attachment 95129 [details] [diff] [review] v1 patch r=dougt
Attachment #95129 -
Flags: review+
Comment 16•22 years ago
|
||
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+
Assignee | ||
Comment 17•22 years ago
|
||
correct... see for example http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsStandardURL.cpp#1031
Assignee | ||
Comment 18•22 years ago
|
||
fixed-on-trunk
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•