leading ".." (Re: revised ...)

"Gregory J. Woodhouse" <gjw@wnetc.com> Sun, 13 April 1997 15:22 UTC

Received: from cnri by ietf.org id aa04422; 13 Apr 97 11:22 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa10244; 13 Apr 97 11:22 EDT
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id LAA17323 for uri-out; Sun, 13 Apr 1997 11:05:08 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com []) by services.bunyip.com (8.8.5/8.8.5) with SMTP id LAA17318 for <uri@services.bunyip.com>; Sun, 13 Apr 1997 11:05:05 -0400 (EDT)
Received: from shell3.ba.best.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27905 (mail destined for uri@services.bunyip.com); Sun, 13 Apr 97 11:05:03 -0400
Received: from localhost (gjw@localhost) by shell3.ba.best.com (8.8.5/8.7.3) with SMTP id IAA07915; Sun, 13 Apr 1997 08:03:30 -0700 (PDT)
X-Authentication-Warning: shell3.ba.best.com: gjw owned process doing -bs
Date: Sun, 13 Apr 1997 08:03:30 -0700
From: "Gregory J. Woodhouse" <gjw@wnetc.com>
Reply-To: "Gregory J. Woodhouse" <gjw@wnetc.com>
To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Cc: fielding@kiwi.ics.uci.edu, uri@bunyip.com
Subject: leading ".." (Re: revised ...)
Message-Id: <Pine.BSF.3.96.970413072524.3662A-100000@shell3.ba.best.com>
X-Url: http://www.wnetc.com/
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-uri@bunyip.com
Precedence: bulk

On Sat, 12 Apr 1997, Foteos Macrides wrote:

> 	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

A lot of people will probably expect something along these lines because
under Unix, both "." and ".." refer to the current directory in the root
directory. So, for example the "/etc/" and "/../etc/" are equivalent. But,
this isn't true of other operating systems (like Windows NT). Besides,
Unix sdrvers will typically not follow Netscape semantics because they
implement URLs through the file system and "public_html" is no the root

Basically, I don't like this kind of pre-processing. It serves only to
imitate the file system semantics of one operating system (sort of), an it
doesn't add in any way to the URL mechanism. (By contrast, I think
relative URLs to express something different from the absolute URLs to
which they resolve.)

> with the consequence that many people are putting HREFs and SRCs
> in their markup which by "valid" parsing rules yield lead
> relative symbolic elements, and sending of "false bug reports"
> to non-Netscape browser developers with one or another variant
> of:
> 	 "It works fine with Netscape."
> 	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.

It's good programming practice to be tolerant of errors (on the part of
the user or otherwise). I suspect some application was generating
incorrect URLs of the type you describe, so Netscape added support for
them. I don't see this as a problem. But the robustness principle doesn't
apply to specifications in the same way. 

> 	I would appreciate your and others' opinions on whether
> it would be good or bad for other browsers to reverse engineer
> for that Netscape URL resolving.
> 				Fote
> =========================================================================
>  Foteos Macrides            Worcester Foundation for Biomedical Research
>  MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
> =========================================================================

gjw@wnetc.com    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
up with a better one.