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.
I think of the adapters as little pieces of the frameworks themselves. Or just a simpler, more isolated alternative to mod_*.
Have you looked at Supervisor for long running processes?
http://www.plope.com/software/supervisor/
I haven't had a chance to use it, but it looks useful for this sort of thing.
Well, there are several such supervising tools (daemontools is another one), but again, they never matched our exact needs. For instance, sometimes it's OK if a process is down ... it could just be that the user is working on his site. And also, they usually only watch one thing: make sure that the process stays up, but there are a million other things we wanted to watch for. So we just wrote our own scripts.
Unlike daemontools, Supervisor is written in Python, which makes it good ;) It also seems like it's meant ot address just the kind of situation you're in -- allowing users to restart servers despite having different permissions, monitoring servers, etc.
Thanks for the tip, I'll take a closer look at it then :-)
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.
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 :-)
Remi. _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
