Re: CGI, semicolons, and so on...
robm@ncsa.uiuc.edu (Rob McCool)
Message-id: <9312301910.AA26941@void.ncsa.uiuc.edu>
From: robm@ncsa.uiuc.edu (Rob McCool)
Date: Thu, 30 Dec 1993 13:10:42 -0600
In-Reply-To: rst@ai.mit.edu (Robert S. Thau)
"Re: CGI, semicolons, and so on..." (Dec 29, 1:46pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: rst@ai.mit.edu (Robert S. Thau), john@math.nwu.edu (John Franks)
Subject: Re: CGI, semicolons, and so on...
Cc: www-talk@nxoc01.cern.ch
Content-Length: 5176
/*
* Re: CGI, semicolons, and so on... by Robert S. Thau (rst@ai.mit.edu)
* written on Dec 29, 1:46pm.
*
* John Franks says:
*
* > Also could you explain why you find the ';' mechanism less flexible
* > than the current syntax. I think the example above shows that the ;
* > mechanism is *more* flexible than the current one. Since it would be
* > trivial to translate the ';' to a '/', I think it is clear that
* > Charles' suggested syntax contains at least as much information as the
* > current syntax and hence is at least as flexible.
* >
* > http://host/path/script;
* > http://host/path/script;foo
* > http://host/path/script;foo?bar
* >
* > would all be scripts. I.e. the presence of the ';' indicates it is
* > executable.
*
* You regard this as more flexible because 'GET /path/script;' runs the
* script, while 'GET /path/script' returns it as a file. I could actually do
* pretty much the same thing --- to have 'GET /path/script' run the script,
* while 'GET /path/script.doit' would return it as a file. I don't, out of
* sheer paranoia --- there is actually an extra line of code which I threw in
* deliberately to *prevent* this from working. To put it bluntly, if there's
* a Bourne shell script on my machine which anyone in the world can run, I
* don't want to let them read it as well without knowing I have done so.
* Some of them are nasty, and some of the nasty ones know more about the
* Bourne shell than I do. But, if that extra line of code offends you, you
* don't have to write it.
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