[URLs in which you can't distinguish the script from its parameters]
* My question is, what's wrong with this? It doesn't confuse me --- I know
* that 'info' is the script, 'rel' is a parameter, and the rest is info file/
* node name --- that's the way I chose to set it up. And as for clients, I
* would tend to view these alternatives as implementation details which are
* none of their business.
I agree completely. I have gotten some rather confused tech support
questions regarding imagemap, so John's point about confusion is valid, but
I think generally people understood when I explained it to them.
* (Really picky observers may note that these aren't
* quite the same as the URLs used by the info gateway I'm actually running
* --- in particular, for back compatibility with an older hack, I'm covering
* up the 'rel' parameter with a ScriptAlias, but this is a reflection of
* what's actually going on under my hood).
Hmm, that breaks the modification I was going to make to reduce the number
of stats required. I'll have to rethink it.
* In fact, I've found the status quo to be in some respects insufficiently
* flexible. For instance, it's awkward to have to put Guy Brooker's archie
* script in a different directory from its coversheet, at potentially far
* remove. To deal with this, I've modified my NCSA httpd so that it is
* capable of running scripts from (some of) the same directories it would
* ordinarily search for files, under control of a RunScripts allow-option.
* (The scripts are distinguished from ordinary files by a naming convention
* which isn't visible to the clients, and PATH_INFO works --- as indicated
* above, I'm using it. BTW, I'd be willing to give the changes out as a
* patch to anyone interested, and willing not to look a gift horse too close
* in the mouth).
Is this like a ScriptAlias in .htaccess files? If so, I could add such a
capability.
* With this all in mind, my comments on the two changes which seem to be on
* the table:
*
* 1) Having a magic character which delimits CGI script parameters ---
*
* I could live with this, although as I say, I really don't think it's
* much of the client's business. However, it would require modifying
* every script out there which takes PATH_INFO --- and every invocation of
* one. (That means every use of imagemap, among many others).
I could live with this as well, but it does in fact break every script out
there. I'm very leery of making Yet Another Incompatible Script Interface,
since we already have two and it's confusing the hell out of people. I don't
know if the potential gains are enough to merit the costs.
* BTW, with regard to the specific point that the status quo requires the
* daemon to do 'wasted' stats to discover where the script name ends, it's
* worth remembering that the daemon may be doing a lot of stats anyway for
* other purposes --- the NCSA daemon, for instance, walks the directory
* hierarchy repeatedly during access checks, looking for .htaccess files
* and symlinks. In any case, compared with the load of running a Bourne
* shell script --- forking and execing a process which is likely to fork
* and exec many more --- these stats are pretty trivial.
Unfortunately under AFS stats are expensive, which is Charles's main problem
as I've seen it. However, it is also worth noting that in things like
directory indexing, future versions (i.e. 1.1) will probably stat the files
in a directory to determine their type, which is costly under AFS.
Of course, as an aside, I'm starting to wonder just what isn't costly under
AFS (yes, we run it here, no I don't run it on my workstation).
* 2) As an alternative, requiring a fixed string at the name of any URL which
* might invoke a script ---
*
* This would set in stone the notion of separate, parallel directory
* hierarchies for scripts and everything else. As indicated above, I
* don't like that notion much at all.
*/
Neither do I.
--Rob