> 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.
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.
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.
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.
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.
rst