51169 - URL: unable to follow "http:././<file>" paths

Status: VERIFIED INVALID

(Core :: Networking, defect, P3)

Description

[Christian Felde]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i586; en-US; m17) Gecko/20000809
BuildID:    2000080923

A link in test1.html found at http://home.powertech.no/cfelde/test/test1.html
points to http:./././test2.html or in other words
http://home.powertech.no/cfelde/test/test2.html. When opening this link in
Mozilla M17 (Build ID: 2000080923), it looks for the domain named ".". When
opening this link in Opera 4.0 or Netscape Communicator 4.72, the file
test2.html is opened in the correct way.

Reproducible: Always
Steps to Reproduce:
1. Go to http://home.powertech.no/cfelde/test/test1.html
2. Click on the link found in test1.html
3. You should now see that Mozilla doesn't open test2.html (as the link points to).

Actual Results:  I get the following error: . could not be found. Please check
the name and try again.


Expected Results:  It should have opened
http://home.powertech.no/cfelde/test/test2.html and displayed the content of
that file.

Source of http://home.powertech.no/cfelde/test/test1.html:

<a href="http:./././test2.html">test2</a>

Source of http://home.powertech.no/cfelde/test/test2.html:

test2 ok!

Comment 1

[Loco]

Confirmed on MacOS 9.0.4 build 2000-09-04-08, Linux 2000-09-05-08, and Win 98 
2000-09-05-08 builds.  Seems like a parser issue to me-the status bar in 4.x 
shows "http://home.powertech.no/cfelde/test/test2.html" whereas in M18 it shows 
"http://./././test2.html.  Seems fairly important to me-increasing severity and 
pawning off on janc.

Comment 2

[Peter Lubczynski]

attempting to triage Clayton's bugs...

Looks like it's not resolving or parsing the URL correctly...over to networking

Comment 3

[benc]

mass move, v2.
qa to me.

Comment 4

[benc]

URL could not be found.

I'll create a new testcase and post it here.te

Comment 5

[regisr]

seems to be the same problan than 32966.
(the same if the URL begins with ../ also)
but the status is won't fix because if the URL contains http: it should have the
hostname in the first field e.g. http://host.domain.tld/page-path and
http:../page-path is interpreted as http://../page-path.

Comment 6

[Ryan Jones-Ward [:sciguyryan]]

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

Comment 7

[Dan Mellem]

I believe this bug is INVALID because a relative URL must be in the form
  relativeURI   = ( net_path | abs_path | rel_path ) [ "?" query ]

which means it would be (relative to http://site.com/path/):
 href="//site.com/path/file.html" - net_path
 href="/path/file.html" - abs_path
 href="./file.html" - rel_path

this should NOT include the scheme (protocol) portion.
 href="http:./file.html" - invalid.

See: (include dots in path)
 http://www.rfc.net/rfc2396.html#s5.  - Relative URIs
 http://www.rfc.net/rfc2396.html#s3.  - URI components


Also, this bug differs from bug 187868 in that this bug deals with relative URIs while bug 187868 deals with absolute URIs.

Comment 8

[Mats Palmgren (inactive)]

I agree with the last comment based on reading the updated RFC
http://www.ietf.org/rfc/rfc3986.txt

which says in 3.3:
   In addition, a URI reference
   (Section 4.1) may be a relative-path reference, in which case the
   first path segment cannot contain a colon (":") character.

and in 4.3:
  absolute-URI  = scheme ":" hier-part [ "?" query ]

and in 3:
      hier-part   = "//" authority path-abempty
                  / path-absolute
                  / path-rootless
                  / path-empty

which means http:. is invalid.

Comment 9

[benc]

V/invalid.

There are numerous URL parsing bugs that support this interpretation. As the parser evolved, we decided not to be liberal about mapping junk into the hostname, in part because it creates a lot of weird security cases. People will just need to clean up their content.