Re: CGI, semicolons, and so on... (Rob McCool)
Message-id: <>
From: (Rob McCool)
Date: Thu, 30 Dec 1993 13:10:42 -0600
In-Reply-To: (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: (Robert S. Thau), (John Franks)
Subject: Re: CGI, semicolons, and so on...
Content-Length: 5176
 * Re: CGI, semicolons, and so on...  by Robert S. Thau (
 *    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.