On our own servers we've been using CGI connectors (wkcgi, Zope.cgi), which seem fast enough, and of course won't be crashing Apache.
Yeah, but we wanted a somewhat "standard" way of talking to Apache and most frameworks do come with a small HTTP server, so that works fine for us and it also completely isolates the process from Apache.
CGI is pretty standard, isn't it?
Are you talking about starting a small CGI script for each request that acts as a gateway between Apache and the other server ? (I think Zope used to call this "presistent CGI"). In that case, then the overhead is not always acceptable.
In my Very Light testing Some Years Ago I found the performance of small C CGI scripts to be quite acceptable. This is something like Webware's wkcgi, Zope's Zope.cgi, the fcgi FastCGI script, etc. If I remember correctly, wkcgi was something like 2x slower than mod_webkit for an empty page, and a Python CGI script was at least 10x slower (but I think significantly more). The size of the typical scripts are small enough to be highly cacheable.
HTTP does seem like a reasonable way to communicate between servers, instead of all these ad hoc HTTP-like protocols (PCGI, SCGI, FastCGI, mod_webkit, etc). My only disappointment with that technique is that you lose some context -- e.g., if REMOTE_USER is set, or SCRIPT_NAME/PATH_INFO (you probably have to configure your URLs, since they aren't detectable), mod_rewrite's additional environmental variables, etc. Hmm... I notice you use custom headers for that (CP-Location), and I suppose other variables could also be passed through... it's just unfortunate because that significantly adds to the Apache configuration, which is something I try to avoid -- it's easy enough to put in place, but hard to maintain.
The CP-Location trick is not needed (I should remove it from this page
as it confuses people).
Have a look at the section called "What are the drawbacks of running
CherryPy behind Apache ?" on this page:
http://www.cherrypy.org/wiki/CherryPyProductionSetup
It summarizes my view on this (basically, there aren't any real drawbacks if you're using mod_rewrite with Apache2).
Does Apache 2 add a X-Original-URI header or something? I see the Forwarded-For and Forwarded-Host headers, but those are only part of the request -- leaving out REMOTE_USER, SCRIPT_NAME, PATH_INFO, and maybe some other internal variables.
I think you're confusing 2 things... The variables you mention are CGI-specific.
Well, they are also the same variables typically used in most in-Apache systems -- you have them in PHP, in mod_python, via FastCGI, etc. WSGI also makes particular use of SCRIPT_NAME and PATH_INFO, which represents more information than a single URL presents. I find all these variables useful. Many could be represented as extra headers -- including something like CP-Location -- but I find the alternative relies too heavily on configuration for my tastes.
I was just talking about mod_rewrite: Apache just forwards the HTTP request it gets to the other server. To this other server, the request will look exactly as if it came from the client, except for 2 things:
- The "Host" header will be "localhost" (assuming Apache and the other server are on the same machine) instead of the actual Host header from the original HTTP request (but you can access the original value through X-Forwarded-Host)
- The remote IP address will be the one from Apache (again, "localhost" if it's on the same machine). But again, you can access the IP address of the client through X-Forwarded-For
- AFAIK, all the other HTTP headers will be kept intact, so it's exactly as if your server was running exposed.
I'm just really advocating mod_rewrite between Apache and the other server because that's how I've been running most of my production sites for the past 5 years and it's always worked great :-)
I've used it a lot too, in a variety of ways, and I'm more-or-less comfortable with it. But I think it provides a challenge to the new user, and can be difficult to debug, so I'm looking for clearer alternatives.
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
