initial "relative-looking" elements.

Larry Masinter <masinter@parc.xerox.com> Sun, 27 April 1997 22:47 UTC

Received: from cnri by ietf.org 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 services.bunyip.com (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 (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id SAA05252 for <uri@services.bunyip.com>; Sun, 27 Apr 1997 18:32:33 -0400 (EDT)
Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07376 (mail destined for uri@services.bunyip.com); Sun, 27 Apr 97 18:32:31 -0400
Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <16187(10)>; Sun, 27 Apr 1997 15:32:27 PDT
Received: from bronze ([13.2.17.209]) by casablanca.parc.xerox.com with SMTP id <71852>; Sun, 27 Apr 1997 15:32:12 PDT
Message-Id: <3363D3E2.3DA9@parc.xerox.com>
Date: Sun, 27 Apr 1997 15:32:02 PDT
From: Larry Masinter <masinter@parc.xerox.com>
Organization: Xerox PARC
X-Mailer: Mozilla 3.01Gold (Win95; I)
Mime-Version: 1.0
To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Cc: fielding@kiwi.ics.uci.edu, uri@bunyip.com
Subject: initial "relative-looking" elements.
References: <01IHMPNKY6JC002J5H@SCI.WFBR.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-uri@bunyip.com
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?