At the time, it was either that or a config file directive. Eventually we
opted for the nph- syntax as the lesser of two evils. If anyone has any
cleaner suggestions I'm listening.
* > 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".
Well, requiring a ; in script names isn't that bad, but again, it breaks
everything that's already out there and I'm really hesitant to do that.
* 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.
Personally, I don't see any added complexity, however, we have to keep the
installed script base in mind. I sure as hell don't want to go into all of
my script-using HTML docs and add a ; to the end of every script HREF.
* 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.
*/
Yes, I agree, it is a syntactical change that should have been included a
month ago, since it avoids a lot of stat()'s and apparently some confusion,
but to me it seems that we should keep what we already have.
--Rob