[Web-SIG] A query for hosting providers

[Remi Delon]

>>> 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.