Re: initial "relative-looking" elements.

"Roy T. Fielding" <> Thu, 01 May 1997 01:16 UTC

Received: from cnri by id aa27828; 30 Apr 97 21:16 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa25564; 30 Apr 97 21:16 EDT
Received: (from daemon@localhost) by (8.8.5/8.8.5) id UAA17687 for uri-out; Wed, 30 Apr 1997 20:55:40 -0400 (EDT)
Received: from (mocha.Bunyip.Com []) by (8.8.5/8.8.5) with ESMTP id UAA17682 for <>; Wed, 30 Apr 1997 20:55:37 -0400 (EDT)
Received: from ( []) by (8.8.5/8.8.5) with SMTP id UAA06386 for <>; Wed, 30 Apr 1997 20:55:35 -0400 (EDT)
Received: from by id aa14296; 30 Apr 97 17:47 PDT
To: Larry Masinter <>
Subject: Re: initial "relative-looking" elements.
In-reply-to: Your message of "Sun, 27 Apr 1997 15:32:02 PDT." <>
Date: Wed, 30 Apr 1997 17:46:26 -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
>> 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."
>Was there any resolution of this issue?

My preference is for a single resolution process that does not make
any assumptions on behalf of the user.  That is why Netscape's (and MSIE 3)
behavior is wrong.

Nevertheless, it is reasonable to say that the spec should not be making
requirements on the parsing of abnormal URL references, and that such
a decision should be a property of the application and not of the
algorithm (i.e., a link tester would be broken if it ignores the invalid
link, whereas a browser would only be stupid).  However, making such an
adjustment to the relative URL resolution algorithm in the spec may not
be easy.