Re: initial "relative-looking" elements.

"Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU> wrote:
>>>         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 [.. MOST browsers, now, are ...] stripping lead relative symbolic
            ^^^^^^^^^^^^^^^^^^^^^^^
>>> elements yielding:
>>> 
>>>         http://host/foo/blah.html
>>>[...]
>>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.

	Larry's question was whether to include some comment about it
in the draft.  I agree it should not change generic parsing rules, but
simply issue a warning, so that its readers are "tipped off" about
problems in the "real world".  It should have the "standard format" for
such warnings, e.g.:

	Note that some UAs inappropriately strip a lead relative
	symbolic path element from resolved paths in requests with
	some schemes.

	You have an equivalent situation for what the draft (and RFC1808)
describe explicitly as a "loophole" when resolving an HREF or SRC that
has a scheme versus a base with the same scheme.  That "loophole" has
been in the libwww, as far as I can tell since the TimBL original, was
clearly intended based on the comment for the code which produces it, and
is the predominant behavior among deployed browsers, ill-advised though it
most certainly is.  So the "tip" about that situation is helpful.  Note
that I tried plugging that "loophole" during field testing, but backed off
in the Lynx v2.7 formal release because there were still too many failures
otherwise in the "real world"  This includes important, content-oriented
documents, not just the "glitz and blitz" stuff.  For example, Koen's
content negotiation page (http://gewis.win.tue.nl/~koen/conneg/) includes:

  <li><a href=http:/conneg-bin/stats>A transparently negotiated page ...
              ^^^^^
and can only be accessed when resolving against an http base with the
loophole open.  That's an "implementation issue" but also worth the
"tip off" in the draft, IMHO.  It's fine being phrased "Hey stupid, you
shouldn't do that!", just as long as the "tip off" is there.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Thursday, 1 May 1997 19:23:36 UTC