john@math.nwu.edu (John Franks)
From: john@math.nwu.edu (John Franks)
Message-id: <9312282330.AA05364@hopf.math.nwu.edu>
Subject:
To: rst@ai.mit.edu (Robert S. Thau)
Date: Tue, 28 Dec 1993 17:30:49 -0600 (CST)
Cc: www-talk@nxoc01.cern.ch
In-reply-to: <9312282232.AA03532@volterra> from "Robert S. Thau" at Dec 28, 93 05:32:55 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3170
According to Robert S. Thau:
>
> First off --- CGI/1.0 already has a naming convention which some people
> find at least irksome, the 'nph-' business.
I too find it irksome. Not horrible, but irksome.
> Secondly --- if scripts and
> ordinary files coexist in the same directories, and the server can't tell
> them apart by the names, then how *can* it tell them apart? How is the
> server to know whether to read the file or to run it?
>
Using Charles Henrich's suggested syntax, for example, URLs like
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. An trailing ';' just indicates an empty PATH_INFO.
>
> > Adding unnecessary complexity to the
> > server is undesirable. You have now added more code to your server
> > and you still don't have the functionality (much less the simplicity)
> > that a very minor change in the protocol would give.
>
> I'm not sure what you're getting at. What functionality don't I have?
> Please be specific --- show me something I can't do.
OK, it is not a big deal, but I do think the current syntax has less
functionality and is less flexible than the one described above. If I
understand you correctly with your server you can't have a script with
an arbitrary path and an arbitrary name. You must either have a magic
directory name like "cgi-bin" in the path above the script or the
script must have a name ending in a special suffix like ".doit". On
my server, I have scripts which are both executed and served as text
documents. Which of these is done depends on how the URL references
them. In the syntax described above, for example, the script would be
executed if the URL ends with ';' and treated as a document
otherwise. I know you can do the same thing by making a symbolic link
to your script with a doit-less name, but this is, as you put it,
just "one more inessential detail to keep track of".
> As to simplicity,
> that's a matter of perspective. As the author of several scripts, I regard
> your proposed changes as *adding* complexity, by giving me one more
> inessential detail to keep track of. Granted, the server code does become
> perhaps a little simpler, but see below for more on how I see the
> tradeoff...
>
Now, could you explain, how the ';' mechanism is more complex than the
current syntax? I find it hard to see how writing a script which
outputs
http://host/path/script;info
is more complicated than one which outputs
http://host/path/script/info
The value of the environmental variable PATH_INFO would be the same
with either syntax, so that couldn't make any difference.
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.
John Franks Dept of Math. Northwestern University
john@math.nwu.edu