httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <>
Subject [PATCH] proposal to add interactive CGI module
Date Thu, 05 Oct 2006 10:09:09 GMT
Hi all,

Patch to enable CGI scripts running from a terminal (shell) to lazily 
request their query_string/body/cookie parameters interactively (rather 
than requiring extra environment variables to be set up, and entity 
bodies to be piped in).


 At my current workplace, we're trying to migrate a lot of old CGI
scripts to work with apreq (among other things).  Once upon a time, well
before apreq 2, we wrote a custom library to do QS/cookie/body
parsing.  When we wrote the library it was enhanced so that
administrative CGI scripts could be run at the command line, and would
automatically prompt the users for missing values.  I think this could
be a useful feature for apreq.  While the existing implementation we
have is a patch against the existing CGI module, my personal thought was
that it might better be made as a separate enhanced-cgi module (which
will still work in dual CGI/interactive fallback mode) - the idea being
that users (users referring to developers who use apreq, not end-users
using CGIs that depend on it) can decide whether they want this
functionality available in their CGI script or not.

Currently, we have a very minimal patch that provides the base
functionality of requesting the body/args/cookies being requested via
stdin/stdout, and storing the received values in the underlying
apr_table_t's (which apreq's CGI module currently use).  The logic
currently being used to detect whether to use interactive mode or not is
based on whether or not the QUERY_STRING environment variable exists
(regardless of whether it's value is set or not).

We also have some ideas for future plans, if people here think it sounds

* Providing support for FILE fields
* Providing support for empty/non-existing parameters
* Providing enhanced support for parameters (will post about this on a
separate thread)
* More maintenance to the existing patch (like removing the 64K buffers
on the stack that we used for quick 'n' dirty reading from stdin)
* Smarter interactive-mode detection
* Smarter storage of data when dealing with mixed
apreq_body/jar/args_get and apreq_body/jar/args calls



View raw message