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

Status: VERIFIED FIXED

(Core :: Networking, defect, P4)

Description

[Emlyn Shannon]

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.

Comment 1

[Emlyn Shannon]

Attachment: Simplified Test Case

Comment 2

[Greg K.]

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?)

Comment 3

[timeless]

Attachment: well... what do you think this should do?

Comment 4

[timeless]

well, this bug is 4xp... and i probably attached that testcase to the wrong 
bug... is this parser?

Comment 5

[sairuh (rarely reading bugmail)]

->parser for triage

Comment 6

[Christopher Hoess (gone)]

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.

Comment 7

[harishd]

Parse does not handle attribute values other than attribute entities. The
problem must be in layout.

Comment 8

[Emlyn Shannon]

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.

Comment 9

[Christopher Hoess (gone)]

->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.

Comment 10

[benc]

-> URL parsing starts in Neworking (core).

Comment 11

[Darin Fisher]

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.

Comment 12

[Darin Fisher]

*** Bug 157987 has been marked as a duplicate of this bug. ***

Comment 13

[benc]

This is is specified in the original URL RFCs 1680 and 1738.

Comment 14

[Darin Fisher]

Attachment: v1 patch

Add input filtering to nsStandardURL::Resolve matching the filtering that we
already do inside nsStandardURL::SetSpec.

Comment 15

[Doug Turner (:dougt)]

Comment on attachment 95129 [details] [diff] [review]
v1 patch

r=dougt

Comment 16

[Alec Flett]

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...

Comment 17

[Darin Fisher]

correct... see for example
http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsStandardURL.cpp#1031

Comment 18

[Darin Fisher]

fixed-on-trunk

Comment 19

[John Unruh]

Verified fixed.