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

[Phillip J. Eby]

At 02:20 PM 12/8/03 +1100, Stuart Bishop wrote:

>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'm -1 on it.  This interface is intended to support *existing* application 
frameworks with minimal glue.  For example, I've successfully run both Zope 
2 ZPublisher and Zope 3 zope.publisher under this gateway 
interface.  Putting in 'None' where a sane CGI environment lacks the 
variable is asking for trouble.


>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).

"errors" is intended to allow access to the web server's error log, as 
FastCGI and other protocols permit.  There are times when it is very useful 
to see application errors in the same context as server errors, so this is 
included for completeness.  A container is free to provide a different 
destination for the errors stream.

Also, this again is for the greatest possible compatibility with existing 
applications and containers.


>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.

AFAIK, there are only maybe 2 or 3 threaded containers currently available, 
and I don't believe any of them have an option *not* to run threading.  So, 
this seems like a YAGNI to me.  I would prefer there to be actual field 
experience with the minimal spec, in order to decide what kind of threading 
categories would be appropriate.

For example, suppose that a threaded container wishes to configure, instead 
of one application object, a factory for returning new application objects, 
so that there is no threading problem?  I think that a premature attempt to 
define threading models in advance of experience/experimentation would not 
only hold up delivery of a usable spec, but could also close off fruitful 
lines of experimentation for container developers.  I'm similarly concerned 
about other forms of deployment parameterization.


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

Dunno why everyone feels so strongly about that one, but if that's what it 
takes to get through, then perhaps we can decide on a small set of required 
methods.

Or, maybe we could simply require that environ.copy() must always *return* 
a dictionary, and then portable apps would only use the copy.  :)