[Web-SIG] WSGI diagram

Graham Dumpleton graham.dumpleton at gmail.com
Tue Aug 21 00:33:52 CEST 2007


On 21/08/07, Cliff Wells <cliff at develix.com> wrote:
> Hi,
>
> There's someone working on a mod_wsgi module for the Nginx HTTP
> server/proxy and Nginx's author was asking if there is a diagram
> somewhere outlining the WSGI protocol (I think perhaps he'd help if he
> understood WSGI).  I google'd a bit but came up empty-handed.
>
> Anyone know of anything?

Start with the PEP:

  http://www.python.org/dev/peps/pep-0333/

Further information may be found on:

  http://www.wsgi.org/wsgi

The official site for the Apache mod_wsgi even references this
information, although the www.wsgi.org site seems to be unavailable as
I write this.

Other than that, the only thing is the various little articles and
blog entries that people have written. There is no exhaustive or
complete description of WSGI with even the PEP leaving various things
unanswered. Generally people ask questions on this list to fill out
the details on what is meant to occur, so perusing the archives would
also be useful.

Some will no doubt say I am biased and trying to protect my turf, but
from what I understand of the aims of Nginx HTTP, in as much as it is
trying to create the fastest web server around, embedding a Python
interpreter within the main server processes would work against that.
This is because supporting Python in an embedded manner may impact
performance in serving static files etc.

Thus, it may make more sense to be suggesting people use the existing
FASTCGI support in Nginx HTTP for hosting Python WSGI applications.
That way you aren't necessarily burdening the main server processes
with the extra overhead. The same argument applies to lighttpd as
well. As to Apache, many have the opinion that it is getting quite
bloated anyway, so adding more stuff into the main server processes
doesn't seem to worry people as much. It does though need to be used
appropriately though.

Also note that WSGI isn't a wire protocol like FASTCGI is. It is more
an programmatic interface definition for adapting a Python application
on top of a specific web server.  If you specifically want to run WSGI
applications in a separate daemon process, then you would need to come
up with your own wire protocol for communicating between the main
server processes and the daemon process. The daemon mode of the Apache
mod_wsgi does this, but since this is what FASTCGI defines anyway,
that is why it may make more sense to use the existing FASTCGI support
in Nginx HTTP and not bother with a separate module. In Apache
mod_wsgi, a new FASTCGI like daemon mode was specifically implemented
to try and come up with an improvement over the sometimes hard to
configure and get working FASTCGI implementations for Apache.

BTW, I hope you would call it something other than mod_wsgi so as not
to cause confusion with the Apache implementation.

Graham


More information about the Web-SIG mailing list