Well, at any rate, that's the way I read it... I'm just following up to
say that coversheets are one reason I like the suffix convention --- I've
got it set up so that if 'foo' and 'foo.doit' are alongside each other, the
file is retrieved as a coversheet in response to parameterless GETs, and
the script is invoked to handle anything else. This is a particular, if
minor, convenience for ISINDEX documents, in which you can't designate
another URL as the locus of the handler. (I know, sooner or later forms
support will be universal and ISINDEX stuff can all go away, but in the
meantime it isn't even available on all common platforms yet).
As long as I'm here, I might as well follow up on a few other points.
I'm not so fond of the prefix convention because as an administrative
matter, I find it awkward to have to designate any directory in which a
script might reside. One of the constraints here is that I'm not the only
person who's putting stuff up on the server, and I don't expect to be the
only script writer here either for very long. If there's a single file
which designates all the script directories, that's one more way for people
to get in each others' hair.
Also, 'ScriptAlias' designation does prevent scripts and other files from
residing in the same physical directory (unless that directory is
double-mapped, which is itself a little awkward, and does leave the door
open to retrieval of scripts as ordinary files as a somewhat undesirable
default). I've found that having coversheets and forms handlers in the
same directory does help keep things organized.
Finally, in regards to 'nph' --- here's a somewhat wooly suggestion: Add
another possible keyword to the keys that the server recognizes when
parsing script output, along with "Content-type:" and "Location:" ---
something like 'Verbatim:'. Then mandate that if the first characters of
the script's output are "Verbatim:\n", the rest of it will be passed to the
client unaltered. As far as I can tell, this is backward compatible. How
about it?
rst