From: rst@ai.mit.edu (Robert S. Thau)
Date: Wed, 5 Jul 95 10:30:07 EDT
Message-Id: <9507051430.AA08589@volterra>
To: new-httpd@hyperreal.com
Cc: new-httpd@hyperreal.com
In-Reply-To: <199507041650.LAA00740@sierra.zyzzyva.com> (message from Randy
 Terbush on Tue, 04 Jul 1995 11:49:57 -0500)
Subject: Re: mod_imap.c 
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

   From: Randy Terbush <randy@zyzzyva.com>
   Reply-To: new-httpd@hyperreal.com

   The sym-link solution is one I admitedly did not consider. I do think
   that the solution I came up with is cleaner since it prevents me from
   having to maintain a web of symlinks.  I may even see a way to fix the
   problem that RST pointed out with a user storing an invalid URL due
   to Location: munging.  I'll see if I can make that work. One note
   about my solution is that I am *only* using the Referer: IF the URL
   listed in the mapfile doesn't have 'http:' in it's URL. I suppose
   that the proposal listed below could make this a bit safer.

In other words, you're only interpreting URLs as relative to something
else if they aren't absolute.  I would certainly hope so!

However, I still think that when someone puts

   rect foo.html 30,40,80,90

in an imagemap file, they are most likely to *expect* that to refer to
foo.html in the same directory as the map file itself, and to be
surprised and dismayed when the server tries (and presumably fails) to
find a foo.html file somewhere else.

NB I'm not saying that using the Referer as a base URI is a bad
idea (you do have a perfectly legitimate application), but rather that
in cases where relative URLs are resolved relative to something other
than the map file itself, there ought to be some notation in the map
file which tells anyone who looks exactly what's going on, so they
some way of figuring out what has happened when it breaks.

rst