Re: initial "relative-looking" elements.

["Roy T. Fielding" <[e-mail]>]

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

....Roy