Re: initial "relative-looking" elements.
Foteos Macrides <MACRIDES@sci.wfbr.edu> Thu, 01 May 1997 23:46 UTC
Received: from cnri by ietf.org id aa01835; 1 May 97 19:46 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa20902; 1 May 97 19:46 EDT
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id TAA11849 for uri-out; Thu, 1 May 1997 19:23:36 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [18.104.22.168]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id TAA11841 for <firstname.lastname@example.org>; Thu, 1 May 1997 19:23:33 -0400 (EDT)
Received: from sci.wfbr.edu (SYSTEM@sci.wfbr.edu [22.214.171.124]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id TAA14826 for <email@example.com>; Thu, 1 May 1997 19:23:31 -0400 (EDT)
Received: from SCI.WFBR.EDU by SCI.WFBR.EDU (PMDF V5.0-4 #19169) id <01IID70SL1O0007991@SCI.WFBR.EDU>; Thu, 01 May 1997 19:22:19 -0500 (EST)
Date: Thu, 01 May 1997 19:22:19 -0500 (EST)
From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Subject: Re: initial "relative-looking" elements.
Cc: firstname.lastname@example.org, email@example.com
X-VMS-Cc: IN%"firstname.lastname@example.org", IN%"email@example.com",MACRIDES
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
"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 =========================================================================