- From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
- Date: Sun, 13 Apr 1997 17:31:14 -0700
- To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
- Cc: uri@bunyip.com
> The rules for resolving partial/relative URLs since the
>beginning of URL time have been such that if relative symbolic
>elements end up at the beginning of paths they should be retained,
>e.g., you can end up with something like:
>
> http://host/../foo/blah.html
>
>but Netscape's parsing ends up stripping lead relative symbolic
>elements yielding:
>
> http://host/foo/blah.html
Yes. I explored these issues on my test pages at
http://www.ics.uci.edu/~fielding/url/
and it is unfortunate that the MSIE 3.01 url parser is actually less
compliant than was MSIE 2.0. Before that, Navigator was the only
application that sufferred from this bug.
The reason that the former (including "/.." in the result) is preferred
is because ignoring the incorrect relative URL portions prevents a
link tester (including manual browsing by the author, or automatic
checking by something like MOMspider) from discovering incorrect URL
references. While it may be true that "It works fine with Netscape"
for the topmost reference, such incorrect relative URLs usually indicate
that an entire tree of resources was moved to the wrong place, and that
the hierarchical references no longer point to what was intended by
the author.
How the standard should account for such abnormal URL references is
a matter of debate. The solution I chose is the one that lets the
author know as soon as possible that the reference is abnormal, rather
than requiring every client to guess what was really intended by the author.
It was my impression that both Netscape and Microsoft agreed with this,
but that they have been too busy fixing other problems.
> I can see retaining the lead relative symbolic elements
>in ftp URLs for personal accounts (would generally fail for
>anonymous accounts), but to my knowledge no http or https server
>would accept such paths, so there's that kind of justification
>what Netscape is doing.
We *want* the server to reject an invalid reference -- that is the
only way that it will be fixed. The sooner the rejection, the earlier
it is fixed.
...Roy T. Fielding
Department of Information & Computer Science (fielding@ics.uci.edu)
University of California, Irvine, CA 92697-3425 fax:+1(714)824-4056
http://www.ics.uci.edu/~fielding/
Received on Sunday, 13 April 1997 20:32:46 UTC