Re: revised "generic syntax" internet draft

"Roy T. Fielding" <> Mon, 14 April 1997 00:58 UTC

Received: from cnri by id aa11128; 13 Apr 97 20:58 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa18309; 13 Apr 97 20:58 EDT
Received: (from daemon@localhost) by (8.8.5/8.8.5) id UAA10725 for uri-out; Sun, 13 Apr 1997 20:32:46 -0400 (EDT)
Received: from (mocha.Bunyip.Com []) by (8.8.5/8.8.5) with SMTP id UAA10720 for <>; Sun, 13 Apr 1997 20:32:40 -0400 (EDT)
Received: from by with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29901 (mail destined for; Sun, 13 Apr 97 20:32:33 -0400
Received: from by id aa13925; 13 Apr 97 17:31 PDT
To: Foteos Macrides <>
Subject: Re: revised "generic syntax" internet draft
In-Reply-To: Your message of "Sat, 12 Apr 1997 20:38:33 CDT." <01IHMPNKY6JC002J5H@SCI.WFBR.EDU>
Date: Sun, 13 Apr 1997 17:31:14 -0700
From: "Roy T. Fielding" <>
Message-Id: <>
Precedence: bulk

>	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

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    (
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056