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!
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
Status: UNCONFIRMED → NEW
Component: HTML Element → Parser
Ever confirmed: true
OS: Linux → All
QA Contact: lorca → janc
Hardware: PC → All
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
mass move, v2. qa to me.
QA Contact: tever → benc
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
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. ***
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 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.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
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.
Status: RESOLVED → VERIFIED
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.