[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cgi.ss, fastcgi.scm, and environment variables



Shriram Krishnamurthi <shriram@cs.rice.edu> writes:

> It's not clear to me why QUERY_STRING would *not* be defined in the
> environment.  Is FastCGI actually *unbinding* it?

        No, not exactly. This is what happens:

,--------------------
| Instead of using operating system environment variables and pipes, the
| FastCGI protocol multiplexes the environment information, standard
| input, output and error over a single full-duplex connection. This
| allows FastCGI programs to run on remote machines, using TCP
| connections between the Web server and the FastCGI application.
`--------------------

So, I'm not amaze (now) that the CGI collection doesn't work out of
the box with FastCGI. Though, it took me a couple of hours to figure
out what was going on, and came up with a workaround. :-(

> Moreover, the binding for QUERY_STRING is defined by the CGI standard
> (for GET requests).  Therefore, if FastCGI is doing something to
> affect this, then the problem is at FastCGI's end.  Put differently,
> if you're using the CGI collection in a context where this isn't
> bound, then you're not really using it for CGI, so it's not surprising
> that it would not work without some monkeying around.

Every word you say here is true, but I bet that most people who will
try to use fastcgi.ss will also want to use the CGI collection. And
WIBNI the README accompanying fastcgi had a warning message or
something? or even better: WIBNI there were a "PLT Scheme: contributed
code FAQ" answering most of the questions people find when using
non-standard extensions? :-)

Thank you,
Francisco
-- 
Fashions have done more harm than revolutions.
		-- Victor Hugo