Lighttpd

we got mod_proxy_backend_scgi.c already. ever thought on using that?

As the OP mentioned, using SCGI requires a middleware library like FLUP to connect SCGI->FLUP->WSGI. Given WSGI is the way forward for "at least" Python deployments, and the current availability of mod_wsgi for apache and nginx, I think this should be looked at, or at least considered carefully before closing INVALID so abruptly.

The incentive and desire to remove Apache out of our web application achitectures is quite high on my TODO list, as I'm sure is the same for other system admins / developers out there.

I would also be looking at a mod_wsgi rather than integrating into mod_proxy.

We will never include blocking modules for generating content. And no, we will not start threading or forking for this. Use apache if you think that would be the right way.

Anonymous wrote:

I'll try to work this out and hopefully can then provide somewhat generic instructions. After all I'm mostly stressed by all the different options to deploy stuff and in most cases you can't find a good example.

Unfortunately, this is still true today, more than 8 years later. Any experienced Python programmer reading this should try really hard to understand that the flexibility of the Python frameworks are great, but the dearth of accessible documentation for newcomers is very frustrating to many people. The WSGI documentation is most useful for those who already know how to do things. Most Python documentation surrounding WSGI is very hard to approach for those new to WSGI.

From the perspective of lighttpd, I'll summarize and reiterate some of the answers already provided.

The "GI" in many of these protocols is an acronym for "gateway interface" protocol. A gateway interface is a description how to communicate across a gateway (e.g. between different processes). For example, CGI ("common gateway interface") is a description of how a web server (which speaks an HTTP protocol to the client) can communicate the client request (HTTP protocol) to a separate process which understands the CGI protocol. A web server sets up the environment, starts the backend CGI process to handle the request, and reads the response from the backend process.

WSGI is even more constrained, and in my opinion, is a Python API and not a gateway interface. WSGI describes an API in Python for Python to run a callable Python application routine to handle a request, and for how that application routine responds. If a web server is a Python-based web server or has the Python interpreter built into the web server, then the web server can implement WSGI API within the web server process. If not, then the web server must use a different gateway interface to communicate to a Python process (which supports that same gateway interface) which can then translate the request to the WSGI API.

lighttpd is single-threaded and does not have any plans to build Python into the lighttpd server since arbitrary Python application code can cause the entire lighttpd server to block.

If you can find the right documentation, it is quite easy to have lighttpd (or other webserver) use any of a number of gateway interfaces to speak to a Python process, which then calls the WSGI API, e.g.

  process     protocol    process
  --------    --------    --------------
  lighttpd -> HTTP     -> Python process (-> WSGI app)
  lighttpd -> FastCGI  -> Python process (-> WSGI app)
  lighttpd -> SCGI     -> Python process (-> WSGI app)
  lighttpd -> uwsgi    -> Python process (-> WSGI app)
  ...