On 16 February 2011 00:45, johnm <[email protected]> wrote:
>
>
> On Feb 15, 3:07 am, Graham Dumpleton <[email protected]>
> wrote:
>>
>> Why wont mod_proxy do the trick? What part of the response headers
>> isn't it leaving alone?
>>
>> If you can't get mod_proxy to work, then only other thing I can think
>> of is you use a CGI script which acts as a proxy. Such as:
>>
>>  http://www.jmarshall.com/tools/cgiproxy/
>>
>> This requires Apache to be setup for Non-Parsed Header (NPH) mode and
>> any back end server headers should get passed through as is presuming
>> the cgiproxy itself doesn't fiddle with them.
>>
>> Otherwise you will need to write your own simply cgiproxy equivalent.
>
> mod_proxy won't do because the interface to the app server listens on
> a domain socket and the communication protocol is non-standard.
>
> I can use a cgi script but then the start up costs are high which is
> what I am trying to avoid.
>
> As I wrote, what I would like to have is a bridge, preferably written
> in python which passes the request info then forwards stream output
> directly to apache. In the future, I my intention is to support fd
> passing between the bridge and the app server to avoid unnecessary i/
> o.
>
> So, I take it that what I am asking for is impossible with mod_wsgi.

Overall, your trying to avoid the re-parsing of the response headers
etc to get it into WSGI form smells of premature optimisation. The
overhead of such a translation is going to be completely insignificant
and is not going to impact on performance. Have you done the tests to
prove that the translation is a bottleneck. This sort of stuff and the
web server itself are pretty well never the bottleneck. Instead the
real bottlenecks are going to be in your application code, database
etc.

So, are you concerned about this because you have shown it is an
issue, or are you simply perceiving that it is bad with no real
evidence?

If you still want to prematurely optimise things then I suggest you
perhaps look at Apache 2.3 (almost in beta) and its mod_proxy_fdpass
module.

  http://httpd.apache.org/docs/trunk/mod/mod_proxy_fdpass.html

This allows you to have the raw socket for a HTTP client passed
through to a back end application which can then read and write
directly to it and so bypass Apache filter mechanisms. The information
on the module is sparse at this time and not sure whether you still
get access to all the request headers etc.

Graham

-- 
You received this message because you are subscribed to the Google Groups 
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/modwsgi?hl=en.

Reply via email to