Re: CGI/1.0 --- what's wrong with the status quo?
john@math.nwu.edu (John Franks)
From: john@math.nwu.edu (John Franks)
Message-id: <9312282046.AA05074@hopf.math.nwu.edu>
Subject: Re: CGI/1.0 --- what's wrong with the status quo?
To: rst@ai.mit.edu (Robert S. Thau)
Date: Tue, 28 Dec 1993 14:46:10 -0600 (CST)
Cc: www-talk@nxoc01.cern.ch
Reply-To: www-talk@nxoc01.cern.ch
In-reply-to: <9312281702.AA03437@volterra> from "Robert S. Thau" at Dec 28, 93 12:02:23 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: 3177
According to Robert S. Thau:
>
[Robert asks what's wrong with the status quo then says]
>
> In fact, I've found the status quo to be in some respects insufficiently
> flexible. For instance, it's awkward to have to put Guy Brooker's archie
> script in a different directory from its coversheet, at potentially far
> remove. To deal with this, I've modified my NCSA httpd so that it is
> capable of running scripts from (some of) the same directories it would
> ordinarily search for files, under control of a RunScripts allow-option.
> (The scripts are distinguished from ordinary files by a naming convention
> which isn't visible to the clients, and PATH_INFO works --- as indicated
> above, I'm using it. BTW, I'd be willing to give the changes out as a
> patch to anyone interested, and willing not to look a gift horse too close
> in the mouth).
>
Well, you ask what is wrong with the status quo and then tell us about
the modifications you have made to your server in order to get around
one of the problems which wouldn't exist if either of the suggestions
made by Charles Henrich and myself were adopted. You are absolutely
right that there is no reason that the script and coversheet should
have to be in different directories. There is also no reason that
directories containing scripts have to be listed in configuration
files and processed on server start up. Or that scripts need to be
distinguished from ordinary files by a naming convention which the
server presumably decodes. 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.
> With this all in mind, my comments on the two changes which seem to be on
> the table:
>
> 1) Having a magic character which delimits CGI script parameters ---
>
> I could live with this, although as I say, I really don't think it's
> much of the client's business.
It is *none* of the client's business -- everyone agrees that the path
part of the URL is opaque to the client. We are talking about making
the *servers* clean and simple and about making things clearer for human
maintainers. All I am saying is SIMPLE IS GOOD. Unnecessary complexity
is bad.
> However, it would require modifying
> every script out there which takes PATH_INFO --- and every invocation of
> one.
>
I have to plead guilty to starting this discussion at much too late a
date. The suggestions should have been made several months ago when
the CGI standard was still in flux. One possibility is that this
issue could be addressed in CGI/1.1. I would point out that nothing
suggested requires any change in browsers and changes to scripts and
servers should be very minimal. I think that relatively few scripts
currently use PATH_INFO.
I would be interested in hearing from server writers, like Rob McCool, Tony
Sanders and the CERN server author. Also the views of script writers
would be valuable. Are there examples of widely used scripts that would
break?
John Franks Dept of Math. Northwestern University
john@math.nwu.edu