[Web-SIG] A query for hosting providers

[Ian Bicking]

Remi Delon wrote:
>>>> 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  /  ianb at colorstudy.com  /  http://blog.ianbicking.org