initial "relative-looking" elements.

Larry Masinter <> Sun, 27 April 1997 22:47 UTC

Received: from cnri by id aa29151; 27 Apr 97 18:47 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa16168; 27 Apr 97 18:47 EDT
Received: (from daemon@localhost) by (8.8.5/8.8.5) id SAA05259 for uri-out; Sun, 27 Apr 1997 18:32:36 -0400 (EDT)
Received: from (mocha.Bunyip.Com []) by (8.8.5/8.8.5) with SMTP id SAA05252 for <>; Sun, 27 Apr 1997 18:32:33 -0400 (EDT)
Received: from alpha.Xerox.COM by with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07376 (mail destined for; Sun, 27 Apr 97 18:32:31 -0400
Received: from ([]) by with SMTP id <16187(10)>; Sun, 27 Apr 1997 15:32:27 PDT
Received: from bronze ([]) by with SMTP id <71852>; Sun, 27 Apr 1997 15:32:12 PDT
Message-Id: <>
Date: Sun, 27 Apr 1997 15:32:02 PDT
From: Larry Masinter <>
Organization: Xerox PARC
X-Mailer: Mozilla 3.01Gold (Win95; I)
Mime-Version: 1.0
To: Foteos Macrides <>
Subject: initial "relative-looking" elements.
References: <01IHMPNKY6JC002J5H@SCI.WFBR.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

The enormous flap over internationalization left me with little
time to deal with other issues. I don't quite understand where
we want to go with some of the other issues.

>         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
> 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.
>         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

Was there any resolution of this issue?