[Web-SIG] Pre-PEP: Python Web Container Interface v1.0
Phillip J. Eby
pje at telecommunity.com
Tue Dec 9 14:32:06 EST 2003
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.
>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
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
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)
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.
More information about the Web-SIG