Re: CGI stuff
john@math.nwu.edu (John Franks)
Errors-To: listmaster@www0.cern.ch
Date: Tue, 1 Mar 1994 16:35:06 --100
Message-id: <9403011531.AA03235@hopf.math.nwu.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: john@math.nwu.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: john@math.nwu.edu (John Franks)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: CGI stuff
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1273
According to Rob McCool:
>
> Hmmm, the problem I was considering was that I believed gopher could not
> support arbitrary types returned by a script. From what I just read of the
> GN documentation, it seems that GN supports it.
GN supports it for HTTP clients only. It is a nice idea, but after
considerable thought I think that use of CGI by gopher servers is
unrealistic for both practical and political reasons. The CGI
protocol could be (pretty much is) protocol independent, but the
writers of CGI scripts are mostly HTTP users and expect an HTTP client
to receive the output of their script. And it wouldn't really be fair
to ask them to do otherwise. I have looked a fair number of CGI
scripts and very few of them would work with a gopher server. For
many (e.g. ismap applications) there is no way to get them to work
with gopher. Also gopher server maintainers are unlikely to adopt CGI
as a standard since many aspects of the protocol seem quite unnatural
in a gopher context.
In short, I think it doesn't make sense to try to bend CGI in a way that
would presumably make it better for the gopher protocol. The real value
of CGI is that it should work with all HTTP servers.
John Franks Dept of Math. Northwestern University
john@math.nwu.edu