50285 - space in relativ url in frameset give 404

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Henrik Gemal]

I'm not sure it's this bug is valid or not. But if a relativ URL in a frameset 
has a leading space the URL doesn't load:

This will not work, resulting in a "HTTP Error 404"
<frameset cols="50%,*">
<frame name="1" src="1.html">
<frame name="2" src=" 1.html">
</frameset>

This will work!
<frameset cols="50%,*">
<frame name="1" src="http://www.mozilla.org/">
<frame name="2" src=" http://www.mozilla.org/">
</frameset>

Build 2000082408 on Win2000

Comment 1

[Chris Brien]

I don't think that's supposed to work. A string literal " 1.html" will look 
for " 1.html", which is different from "1.html". If you leave out the quotes, 
though, it should work.

Comment 2

[Henrik Gemal]

It worked in Netscape 4.x, but that doesn't mean that it should work in 
Mozilla....

Comment 3

[tenthumbs]

Lynx also strips leading white space before creating a URL. Mozilla isn't
consistent; it will strip trailing white space, e.g.
  <A HREF="foo.htm ">foo</A>
will work. I couldn't find anything in the HTML 4.01 docs or RFC1808 or RFC2396
as to how a client should contruct a absolute URL from a relative one. Stripping
leading and trailing white space seems liek a good idea.

Comment 4

[Eric Pollmann]

This is a general problem with relative URL parsing.
I.e., <A HREF=" foo.html">click</A> does not link to foo.html

CC'ing Andreas, the URL parsing guru.  This seems like it might be a problem
with NS_MakeAbsoluteURI... or a variant or child thereof

Comment 5

[Andreas Otte]

I'm currently in Dawson City, I can't work on the code, but this is definitly a 
problem with relative url parsing. I'm sure stripping the spaces was in there 
at some point in time, at least in my tree. I will put it in when I return in 
one week.

Comment 6

[Andreas Otte]

Attachment: patch to fix the problem

Comment 7

[Gagan]

Welcome back Andreas. Pls. check with waterson, since he was resolving some of 
the similar leading white space issues. am cc'ing him.

Comment 8

[Chris Waterson]

Andreas, I'd taken the approach of moving the leading & trailing whitespace 
stripping to the place where the local URL was resolved (e.g., parsing the 
"src=" attribute on the image tag). I thought this seemed "safer", mostly 
because I remember there being silly issues with filenames that contained 
whitespace characters (esp. on Mac) in 4.x. Thoughts?

Comment 9

[Andreas Otte]

If there is such a thing as a filename on any supported os (or even an os that
can be or have programs that run as a webserver) that can start with a
whitespace, we should leave the code in Resolve just as it is currently. I
wouldn't even do a parse on the src tag/removing the trailing whitespace there.
I think we should expect from every web developer to be able to create documents
that adhire to the docs/rfcs/etc ... In this case I think a string like 
" test.html" is something different as "test.html" when used in a relative URL.

Is there such an os? Mac-Os?

Comment 10

[Chris Waterson]

andreas: it's likely that this was fixed by jst's recent changes to 
nsFrameFrame.cpp for bug 48763.

Comment 11

[Andreas Otte]

Okay, may be so, but I'm more concerned with the general problem, which is a
problem for every location where a relative url is converted into an absolute
url. I think we need a clear decision on how to handle such cases in general not
just in case of frames or something similar.

Comment 12

[Chris Waterson]

I can create a file on Linux that starts with whitespace by typing:

  % touch " foo"

or

  % touch \ foo

Comment 13

[Andreas Otte]

Okay, then it is settled I think. Forget the patch. Mozilla's current behaviour
as described in this bug is right, although it might not be compatible with 4.x.
The 404 is the right thing to do. If nobody subjects I will mark this bug
INVALID.  

Comment 14

[Chris Waterson]

See my comment above: I think that jst has fixed this bug already.

Comment 15

[Henrik Gemal]

fixed in build 2000090808 on win2000

Comment 16

[Andreas Otte]

Yes, he has, sort off ... He is doing a trim ...

That was what I wanted to say. After carefully looking into this and considering
your comments about filenames that can start with a leading whitespace, I think
this fix is wrong. I can easily create a file that starts with a leading
whitespace (say " test.html"), do a correct src=" test.html" and would get a 404
now. That can't be right.

There must be another way to fix bug 48763, don't do the trim ...

Comment 17

[Hixie (not reading bugmail)]

Spaces in HREFs should be escaped as %20. It is INVALID to have a space in an
href. Spaces at the start and end should be trimmed according to the HTML spec.

Comment 18

[Andreas Otte]

This is a valid point. I found nothing about leading or trailing whitespace
regarding relative url. That can either be interpreted as handling it as absolut
urls (trim it) or not. If we go for the trim of relative urls then we should do
it inside Resolve to make it work in all relative cases. 

Comment 19

[Hixie (not reading bugmail)]

The spec (HTML4.01) says CDATA attributes (the HREF attribute is a CDATA 
attribute) should have leading and trailing whitespace trimmed, and inner 
whitespace collapsed, with linefeeds turned into spaces first. This is actually 
an SGML requirement.

Comment 20

[Henrik Gemal]

build 2000091108 on win2k