Python on the Web

[Graham Dumpleton]

A few additional comments on top of what others have said.

On Aug 26, 11:09 am, Phil <phil... at gmail.com> wrote:
> I've seen lots of web sites explaining everything, but for whatever
> reason I seem to not be picking something up.
> I am a graphical person, which is probably the reason I haven't found
> my answer.
> May somebody please confirm if my diagram accurately represents the
> stack, generally speaking.
>
> http://i26.tinypic.com/1fe82x.png
>
> Even if that is the case, I'm having a hard time understanding the
> differences. I guess wsgiref has absolutely nothing to do with FCGI/
> SCGI/CGI and simply receives and responds to HTTP requests following
> the WSGI specification?

Technically it receives and responses to request based on HTTP
specification, not WSGI specification. The underlying HTTP server
translates to and communicates with a Python web application using the
WSGI interface.

> Does it just spawn a new thread for each
> request? If so, then how is this any different than a production
> server with FCGI?

I would describe there as being four major ways that WSGI can be
hosted. These are:

1. Custom build HTTP/WSGI server written in Python. Production quality
examples are CherryPy WSGI server and Paste HTTP server. You shouldn't
use wsgiref for anything but very simple stuff.

2. Per request process execution by way of CGI and a CGI/WSGI adapter.
This could be under Apache or any other web server which supports CGI.

3. Module that embeds Python interpreter into a C based web server.
Example are mod_wsgi and mod_python for Apache. Note that mod_python
would infrequently be used to host WSGI and doesn't include its own
WSGI adapter. These days mod_wsgi for Apache would be used. Processes
in this would be persistent.

4. Module in a web server that allows one to communicate using a
custom protocol with a separate persistent web application process
hosting the web application through a WSGI interface. This convers
FASTCGI, SCGI and AJP. The mod_wsgi module for Apache has a hybrid
mode which work in a similar way but uses an  internal protocol.

Amongst these, there are many variations as far as number of process
and threads. For a bit of discussion about this in relation to
mod_wsgi read:

  http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading

> The way I am understanding the 'Production' side of that picture is
> that the web server (eg. lighttpd) creates a single FCGI process.

FASTCGI isn't restricted to a single process, nor single threading.
Whether a particular implementation allows for the variations depends
on the implementation.

> The
> FCGI process is actually the entry point of the Framework/Application
> which sets up Flup's WSGIServer, being the interface between FCGI and
> the Framework/Application? What I mean is, it is just the code that
> the web server loads to start with, example...
>     from flup.server.fcgi import WSGIServer
>     from app import application
>     WSGIServer(application).run()
> ... Then for each HTTP request, Flup's WSGIServer creates a new thread
> to handle the request?
>
> As I've read elsewhere, "These days, FastCGI is never used directly.

Even back in time, I don't think it was really ever used as a generic
interface that people worked with directly, there was always a more
usable layer built on top of it.

> Just like mod_python it is only used for the deployment of WSGI
> applications.

The mod_python module isn't used just for WSGI applications and is
probably rarely used for them. This is because mod_python has its own
interface for building web applications. It also has abilities to hook
into Apache request handling phases, meaning it can do more than host
a a content handler/web application.

> As far as I understand, the main (or only?) reasoning
> for this is because WSGI makes Python applications easier to deploy
> without having to worry about whether using FCGI/SCGI/CGI.

WSGI provides for portability, it isn't necessarily easier to use than
mod_python.

> What would be involved to run Python on the web using FCGI without
> WSGI? I can feel the flames already.

No, you really don't want to do that.

> This isn't the only reason I want
> to know, but one reason is that I want to use Python 3.1 and as I
> understand, this will have to wait for the WSGI 2.0 specification to
> ensure time isn't wasted.

Then look at mod_wsgi. It already has support for Python 3.X. Some
aspects of how it implements WSGI 1.0 may change, but will not be too
much and details are being sorted out in the back rooms as we speak.
See:

  http://code.google.com/p/modwsgi/wiki/ChangesInVersion0300

The other option is CherryPy WSGI server as that is close to a Python
3.X release as well, as I perceive it.

I wouldn't bother waiting for WSGI 2.0. That is more of a pipe dream.
There will be an updated WSGI 1.0 for Python 3.0.

Graham

> I apologize if the questions are ridiculous. I've just recently got
> into web programming and it seems that in order for me to use Python,
> I need a deep understanding of web servers, HTTP, FCGI, etc. I have
> more questions but they go more off topic, so I will save it for
> another thread, another day.
>
> I realize there is a large number of questions, so thanks for any help.