Return-Path: owner-new-httpd Received: by taz.hyperreal.com (8.6.12/8.6.5) id IAA15766; Tue, 4 Jul 1995 08:38:15 -0700 Received: from life.ai.mit.edu by taz.hyperreal.com (8.6.12/8.6.5) with SMTP id IAA15761; Tue, 4 Jul 1995 08:38:13 -0700 Received: from volterra (volterra.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) for new-httpd@hyperreal.com id AA28846; Tue, 4 Jul 95 11:38:11 EDT From: rst@ai.mit.edu (Robert S. Thau) Received: by volterra (4.1/AI-4.10) id AA08248; Tue, 4 Jul 95 11:38:07 EDT Date: Tue, 4 Jul 95 11:38:07 EDT Message-Id: <9507041538.AA08248@volterra> To: new-httpd@hyperreal.com Cc: new-httpd@hyperreal.com In-Reply-To: (message from Brian Behlendorf on Mon, 3 Jul 1995 16:33:31 -0700 (PDT)) Subject: Re: mod_imap.c Sender: owner-new-httpd@apache.org Precedence: bulk Reply-To: new-httpd@apache.org Date: Mon, 3 Jul 1995 16:33:31 -0700 (PDT) From: Brian Behlendorf If you're saying that you have a bunch of directories with a bunch of common subdirectories that you want one map file to serve, then yes, I suppose you'd have to look at Referrer to get the context, since the Location: header returned has to be a full URI, not a relative one. That seems rather specific - it could also be accomplished by having soft links to the imap file between directories. *shrug*. That is what he's after. I think it's important to keep the functionality as solid and generic as possible... I named my tweak "imagemap2" because it's not a drop-in replacement for one. Hmmm... on the one hand, Randy's got a legitimate application, for referer-relative URIs in the maps (and it may even work!). On the other hand, I am a bit worried that it may prove to be flaky, and also that having relative URIs in a map file be interpreted relative to anything other than the map file itself might fail to satisfy the Law of Least Astonishment (which is that good software always behaves in the manner that astonishes the user least). How's about this for a compromise --- toss a new directive, base_uri, into the mapfile syntax, which specifies the interpretation of relative URIs which occur in subsequent map directives. I figure on a subcommand set like: base_uri map # relative to the map itself base_uri referer # relative to the Referer: supplied by the browser base_uri path_info # relative to whatever came in as PATH_INFO # for the request (which gives the document that # included the map complete control over # how relative URIs are interpreted). base_uri /literal/dir/ # Why not? It could save someone typing ;-). My proposal is, then, to make "base_uri map" the default, but to have the other options available if anyone wants them. The syntax is a straw man, of course. Comments? rst