John, correct me if I'm wrong, but I believe you were referring to a method
in which GET /path/script would return a cover page, and GET /path/script;
would execute a script.
This is fine, except I would REALLY like to see the scripts and documents
transparent. The original goal of the scripts was to make documents on the
fly... I would like to be able to interchange scripts and documents when I
feel like it, for instance, when a script is no longer being offered.
* The flexibility that concerns me more is my flexibility to decide whether a
* particular URL is going to run a script at all, or not --- and having made
* that choice, to change my mind. Suppose, for instance, that I have a
* document which is frequently referenced, and I want to add something to it
* for local eyes only. One thing I could do, with my current setup, is to
* turn it into a script, which only prints certain parts of the boilerplate
* if the connection has come from inside the lab.
Yes, this goes back to the point being made earlier (I just sent the note a
few minutes ago) about having to change references to scripts. I don't want
to see scripts being referenced explicitly with a ;, I would much rather use
config file directives or suffixes.
* Now, with your variant of Charles' proposal, this means changing the name
* of it as well --- I'd have to add that extra semicolon. Then, I'd have to
* either track down and change all the references to the old name (a messy
* chore), or add a Redirect line to srm.conf (which gets ugly when they start
* to pile up). And --- to return to an earlier point --- if I wasn't
* extremely careful about how I wrote the script, then a client who left off
* the semicolon would get to see the eyes-only matter anyway, and find out a
* little about my security setup as an added bonus. ("Oh, so he trusts the
* nameserver? Hmmmm....") Because the client can read the script, the whole
* point of having a script there in the first place has been lost. This sort
* of thing is why I *don't* regard the free export of the code of the scripts
* that I'm running as an "inessential" matter.
I don't know if the point was being able to get the source to a script as
much as it was to get the cover sheet for a script.
* In short, what I mean by flexibility is the ability to make these kinds of
* changes --- turning an ordinary file into a script, etc. --- without having
* to track down all the references and change *those* as well. Requring
* special syntax to invoke a script denies me this flexibility; it makes what
* *ought* to be local changes into global ones.
I agree, the server has domain over what is after the third /, which has
always been reflected in NCSA httpd's design. Whether a document is a script
or a document is the domain of the server alone, and I think we need to keep
the arbitrary nature of script execution.
* So much for my "flexible". Now, I'm still confused by your "functional"
* --- since, as we seem to agree, there is no script which *couldn't* be
* written to work either way, it seems to me that there is no difference in
* functionality whatever. It's just that (aside from the question of
* changing a "standard" after it was promulgated), one thing is, IMHO, rather
* easier to keep secure and to administer.
*/
To throw in some of my chips, I would have gladly added Charles's ORIGINAL
proposal (i.e. just replace the first / of the path info with a ;) to CGI
had it been made a month ago, but I feel it's too late now. I don't like the
idea of requiring a ; in every script execution.
--Rob