[Web-SIG] Pre-PEP: Python Web Container Interface v1.0

[Stuart Bishop]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 08/12/2003, at 5:53 AM, Phillip J. Eby wrote:

> In other words, an application calls
> ``app.runCGI(input,output,errors,environ)`` to invoke the application.
> The ``runCGI`` method should read from ``input``, if required, and
> write its response to ``output``, using the ``environ`` dictionary
> to obtain other information about the request.  Error messages or log
> output may be written to ``errors``.  The return value of ``runCGI``
> is ignored by the container.  The contents and format of ``input``,
> ``output``, and ``environ`` are defined by the Common Gateway
> Interface [2]_.

Should environ['REMOTE_USER'] return '', None, or raise a KeyError if 
the
web server has performed no authentication on a request? Some keys
should always have valid values available (REQUEST_METHOD), but others
only for some requests (CONTENT_LENGTH, REMOTE_USER). We don't want
applications raising KeyError exceptions when moved to different
frameworks because of frameworks handling this differently. +1 for using
None for missing/meaningless value, and accessing any variable defined 
at
http://hoohoo.ncsa.uiuc.edu/cgi/env.html will never raise a KeyError.

I don't think errors should be a file - we now have a logging package
so we might as well use it. We could pass in a Logger instance, although
I'd just scrap the argument and let the handler instantiate the Logger
if it wants one. The container could define a Handler that sends the 
log messages to the 'standard' location (eg. CGI's Handler would just 
be a
StreamHandler that uses sys.stderr).

> Thread support, or lack thereof, is also container-dependent.
> Containers that can run multiple requests in parallel, *should* also
> provide the option of running an application in a single-threaded
> fashion, so that applications or frameworks that are not thread-safe
> may still be used.

A thread_safety method should be provided by the application. It should
be specified only once, rather than in every container that invokes the
application. The thread_level might be generated programatically, eg.
by querying a DB-API database Connection's thread_safety attribute.

> The rationale for requiring a dictionary is to maximize portability
> between containers.  The alternative would be to define here some
> subset of a dictionary's methods as being the standard and portable
> interface.  In practice, however, most containers will probably want
> to use a simple dictionary anyway, and some frameworks may end up
> relying upon the fact that most containers do this.  So, in the
> interest of a simple specification, and because there is little need
> for a custom type here anyway, a Python dictionary is mandatory for
> communicating the CGI environment.

Or just 'environment should be a standard mapping, or subclass of 
``map``
or ``UserDict``.

- --  Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/


- --  
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQE/0+4DAfqZj7rGN0oRAlphAJ9wEqZt835o4IDl2QjnBvTVT8X2BwCePFCG
qMqU+BCwk8aZKMNKBt5Qc3M=
=yAPk
-----END PGP SIGNATURE-----