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




18 years ago
10 years ago


(Reporter: Christian Felde, Assigned: Gagan)



Firefox Tracking Flags

(Not tracked)




18 years ago
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

18 years ago
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.
Severity: normal → major
Component: HTML Element → Parser
Ever confirmed: true
OS: Linux → All
QA Contact: lorca → janc
Hardware: PC → All

Comment 2

18 years ago
attempting to triage Clayton's bugs...

Looks like it's not resolving or parsing the URL correctly...over to networking
Assignee: clayton → gagan
Component: Parser → Networking
QA Contact: janc → tever


18 years ago
Target Milestone: --- → Future

Comment 3

17 years ago
mass move, v2.
qa to me.
QA Contact: tever → benc

Comment 4

17 years ago
URL could not be found.

I'll create a new testcase and post it here.te
Summary: Unable to use link in test1.html pointing to test2.html. → URL: unable to follow "././<file>" paths

Comment 5

17 years ago
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.

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

Comment 7

12 years ago
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.
I agree with the last comment based on reading the updated RFC

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.
Last Resolved: 11 years ago
Resolution: --- → INVALID

Comment 9

10 years ago

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.


10 years ago
Summary: URL: unable to follow "././<file>" paths → URL: unable to follow "http:././<file>" paths
You need to log in before you can comment on or make changes to this bug.