[Web-SIG] Pre-PEP: Python Web Container Interface v1.0
stuart at stuartbishop.net
Sun Dec 7 22:20:28 EST 2003
-----BEGIN PGP SIGNED MESSAGE-----
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 _.
Should environ['REMOTE_USER'] return '', None, or raise a KeyError if
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
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
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
- -- Stuart Bishop <stuart at stuartbishop.net>
Stuart Bishop <stuart at stuartbishop.net>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----
More information about the Web-SIG