- From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
- Date: Wed, 30 Apr 1997 17:46:26 -0700
- To: Larry Masinter <masinter@parc.xerox.com>
- cc: uri@bunyip.com
>> 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
Received on Wednesday, 30 April 1997 20:55:40 UTC