[Zope] Re: why will FastCGI not be supported in the Future.

[Tino Wildenhain]

David Bear schrieb:
> 
> 
> On 12/10/05, *Tino Wildenhain* <tino at wildenhain.de
> <mailto:tino at wildenhain.de>> wrote:
> 
>     Am Mittwoch, den 07.12.2005, 09:39 +0000 schrieb Chris Withers:
>     > Dieter Maurer wrote:
>     > > The original poster explained his wish to retain FCGI:
>     > >
>     > >   It reuses an existing connection between Apache and Zope
>     > >   while (he thinks and I might believe it) the recommended
>     > >   "mod_proxy" way each time opens a new connection.
>     > >
>     > >   Thus, FastCGI might be more efficient.
>     >
>     > Show me some evidence proving that fcgi or mod_proxy is the
>     significant
>     > limiting performance factor in a setup involving zope and I'll
>     take this
>     > seriously ;-)
> 
>     The funny thing is - performance isnt really the pro of
>     fcgi over http. Its really more about transporting header
>     and environment data from zope to apache, which is
>     kinda limited with mod_proxy. (Think alternative
>     authentication, ssl )
> 
> 
> 
> This was my  reason for going with  fastcgi instead of modproxy. I
> wanted zope to also log the http header data from the client. I want to
> have zope make some decisions based on the user agent. If modproxy can
> preserve ALL the request headers that I suppose I can use it. I somewhat
> understand fastcgi. I don't understand everything mod-proxy does...
> (well, its more magical than fastcgi)

mod_proxy passes all relevent headers. Even user-agent.
But serious web development should never try to depend
on the useragent string. (it can and will be faked - and
you will have a hard time to know all possible user-agents
out there (I occassionally browse as google - you would
be surpriced what you see :))

The only hard part is ssl-client certificate or other
apache side auth information. Auth-headers (basic auth)
are of course passed.