- From: <kweide@tezcat.com>
- Date: Fri, 1 Nov 1996 14:11:24 -0600
- To: jjames@firstfloor.COM
- Cc: www-lib@w3.org
>We're still running wwwlib 3.1, but this would seem to be a basic question >regarding what HTSimplify is doing. > >Given a page www.someplace.com and an IMG entry ../images/mygif.gif, putting >them together as [7]http://www.someplace.com/../images/mygif.gif and calling >HTSimplify gives the same thing back as what goes in. In this particular >instance, I happen to know the correct url is >www.someplace.com/images/mygif.gif, and the server is sending back a 404 on >doing a HEAD or GET when sending over the url with the .. in it. as it probably should. >I've read over the relative URL RFC, and it talks about what to do when you >get something of the form www.someplace.com/a/b/../../c.gif (I believe >simplify it to /a/../c.gif, though I'm at home and doing this from memory), >but it doesn't seem to indicate in my reading what to do when you don't have >some leading subdirectories to work with from the beginning. RFC 1808 does specify it. Since there isn't any preceding path segment, it's obvious that none of the rules for simplifying away the ../ apply, which means it stays as-is. You would get the same result by applying the step-by-step procedure in section 4. > (As an aside, I >don't believe HTSimplify would return /a/../c.gif anyway.) Should be easy enough to check... And I think it would, and it should. >What is the correct behavior in attempting to simplify this URL? The Library is doing the right thing (in this case). I have converted the examples from RFC 1808 to HTML with anchors for the realative URLs, to check "live" what a browser really does in each case. (If anyone wants a copy, mail me.) The Library fails some of the examples (about 10 out of 39). >Do I >arbitrarily pull the .. off the front because I know it's not possible to >climb above the root of the document root? No. (although some clients may do this, it's not the right thing.) >Is the server actually in error >in this case? The server is doing whatever it is configured to do. (including default actions for an URL which it is not configured to serve.) Such absolute URLs (with remaining ../ segments in them, after relative URL resolution) are usual the result of user (i.e. page author) errors. > > John > >--------------------------------------------------------------- >John James Email: jjames@firstfloor.COM Klaus
Received on Friday, 1 November 1996 15:11:38 UTC