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

[Phillip J. Eby]

At 12:29 PM 12/9/03 -0500, Gregory (Grisha) Trubetskoy wrote:
>On the surface this appears fine, but consider setting an HTTP header.
>Headers do not fit into the above-mentioned primitives, so CGI requires
>the application to send them to stdout. Writing headers to stdout is much
>more cumbersome than passing them in a mapping object of some sort.

This is a non-problem.  You can't wave your hand without hitting at least 
half a dozen *already written*, documented, even supported libraries that 
handle this in as many ways as one might like.  And plenty of people 
obviously find them to be of adequate performance and usability.


>  And
>most web server's CGI implementations do not pass the header portion of
>stdout straight to the client. They actually parse those headers,
>optionally alter them and adjust their own behavior based on the header
>information, then add the resulting data to the server header structure
>(e.g. headers_out table in case of Apache). This is inefficient, and ugly.

...and implemented, and documented, and portable, and highly available, and 
widely accepted.

Practicality beats purity.


>Whatever spec we come up with, IMO should deal in terms of the HTTP
>protocol request, headers, body, etc. Trying to narrow it down to input,
>output and environment is fitting a square peg into a round hole.

I think perhaps there's some confusion about the PEP's goals here.  It is 
in no way intended to be an ideal spec, a pure spec, or an efficient 
spec.  It's *absolutely* not trying to be another framework.  It is aimed 
solely at being an *implemented* and *universally available* spec -- right 
now, today, without waiting for another version of Python or trying to 
convince people to use it *in place of* their existing working 
tools.  Rather, the spec should enable people to use other tools in 
*addition* to their existing ones.

Note that this does not preclude the existence of other specifications for 
more advanced capabilities.  However, such specs will naturally be less 
frequently available or implemented.  Meanwhile, there's scarcely a server 
in existence that doesn't support CGI.


>Three other notes:
>
>1. On the threading point - aside from thread-safety there is another big
>issue, it's the shared memory space. Some frameworks assume that they are
>running in one process and take it for granted that making something
>global will make it available to all other requests, which obviously isn't
>going to work on per-process servers.

That's true.  Such frameworks, however, will need to document that they 
will only work in single-process containers.  Users will then correctly 
perceive this as a limitation of the framework.

But it's an important point to add to the spec.  Thanks for pointing it out.


>2. If we're going to refer to a CGI specification, then we should rely on
>the RFC draft at http://cgi-spec.golux.com/. The stuff at NCSA's hoohoo
>page is more of a joke than a spec.

Thanks for the reference; I took the first thing that came up in Google 
that seemed informative.  :)


>3. Mod_python *can* be threaded on apache 1.3, because 1.3 is threaded on
>Windows.

My mistake, sorry.


>Considering that Apache, IIS and iPlanet (or whatever it's called
>now) account for vast majority of the web servers out there, there are
>likely more threaded servers than not threaded, so I wouldn't through out
>thread-safety as a non-consideration.

I was referring to existing, available containers written in/for Python 
code, but I can certainly see that might be the case.  But it still doesn't 
change the possibility of containers having different threading 
models.  For example, some servers may use dedicated per-application thread 
pools.  Others might have a generic thread pool.  Some might pre-allocate 
application objects, others might allocate on demand.

Whatever the model, these are things that a container must 
configure.  Explicit being better than implicit, it would be better to 
configure these things in the container.  And because "in the face of 
ambiguity, refuse the temptation to guess," I don't want to guess what 
threading settings can or should exist and define a spec for them, nor 
should containers try to guess their settings from an ambiguous "I'm (not) 
threadsafe" flag.

Thus, the intent to merely provide a transport conduit, rather than a 
configuration mechanism.  I'd prefer to leave a threading spec to version 
2.0, *after* there's widespread adoption -- and therefore widespread 
experience with -- the needs of containers and the issues of applications 
operating under the 1.0 spec.