initial "relative-looking" elements.

Larry Masinter (masinter@parc.xerox.com)
Sun, 27 Apr 1997 15:32:02 PDT


Message-Id: <3363D3E2.3DA9@parc.xerox.com>
Date: Sun, 27 Apr 1997 15:32:02 PDT
From: Larry Masinter <masinter@parc.xerox.com>
To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Cc: fielding@kiwi.ics.uci.edu, uri@bunyip.com
Subject: initial "relative-looking" elements.

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?