httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: mod_serf is in trunk
Date Tue, 13 Nov 2007 21:58:40 GMT

On 11/13/2007 04:39 PM, Justin Erenkrantz wrote:
> On Nov 13, 2007 6:06 AM, Plüm, Rüdiger, VF-Group
> <> wrote:
>> I agree here. While I would see a benefit of providing a http(s) client
>> API to httpd via serf and thus getting rid of the somewhat strange
>> way mod_proxy_http does its requests to a backend system ,I see no
>> benefit at all adding another "http reverse proxy only module" for
>> the same reasons above. So also -1 from me.
> I'm very much okay with having competition and bake-offs.  We have a
> number of modules that do similar things (mod_alias / mod_rewrite,
> etc.).

Competition is fine and maybe my response was a little harsh, but OTOH
at least for me the initial mail regarding mod_serf had a little bit
of the attitude 'mod_proxy as a whole is crap and here is an nice and tight
replacement'. But maybe I am too touchy here :-).

> I find that mod_proxy is incredibly complex and doesn't even do the
> things that it claims to do properly.  Rather than spend an inordinate
> amount of time trying to fix it, I think we'd be better off trying to
> go in a completely different direction with our proxy code and see
> where it takes us.

It is true that mod_proxy is complex, but partly this is because it has
many features, so I think we need to differentiate here:

1. There is the framework mod_proxy offers that allows to plugin different
   backends (currently http(s) / ajp / fcgi) and that offers load balancing
   with provider based policies. Maybe I am wrong, but I cannot see serf
   helping us here. If we see need for improvements here I guess its easier
   to fix them then to start from scratch, at least I believe so unless
   I see a nice and tight new framework :-).

2. There is mod_proxy_http which had numerous bugs in past and I guess still
   has some. Thanks to Nick we made huge progress to fix some of the RFC
   violations here. But as said I totally agree that the approach how mod_proxy_http
   does http requests is to say the least 'weird'. Using the input filter chain
   for the response and the connection hook for creating connections has some
   nasty side effects. So I am very much +1 for an alternate mod_proxy_http
   module based on serf. It would give us the best out of 1. and serf.
   But to be fair to mod_proxy_http: I think it currently attracts much more
   attention and testing than serf and so much more bugs appear on the surface
   (especially regarding RFC violation). Of course this neither means that
   we would suffer the same with serf if it was the base of mod_proxy_http nor
   that I think that serf is untested code.

3. I remember a general discussion about the current brigade and bucket system
   in httpd and the opinions that serf's concept and implementation of buckets
   and brigades is better and should be adapted by httpd. As I did not have the
   time so far to get a deeper view into the brigade and bucket system of serf
   I cannot really comment on this. But if the concept is better it makes sense
   to adapt it for 3.0. But this goes far beyond mod_proxy.

> Paul has an initial 'starter' version for us to play with - others can
> add features.

As said I would have been more lucky if this module were a replacement for
mod_proxy_http and would fit in to the mod_proxy framework.

>> IMHO we should focus on providing a http(s) client API to httpd for 2.4 or 3.0
>> via serf whose main consumer would be mod_proxy_http. Other consumers
>> would be possible mod_cache for prefetching tasks and mod_ssl for
>> OCSP checks. Currently there are problems of doing the needed http requests
>> for OCSP with mod_proxy due to the early stage in connection handling in
>> which these requests are needed.
>> It may even make sense to put this http(s) client API in apr-util and
>> use serf as the provider of this functionality in apr-util.
> I think adding such a layer to apr-util would be unnecessary bloat as
> we don't need to have a layer of indirection here.  If we want to use
> serf, call serf directly...  -- justin

I think this also depends on our general policy regarding external libraries:

Currently we use the SSL library (openssl in most cases) and the pcre library
directly in httpd. All other libraries are used via apr-util and the SSL layer
is on the move to apr-util. OTOH I think serf and pcre have API's we want to use
directly in httpd in contrast to e.g. ldap, dbm or also SSL API where there are
multiple libraries that implement the functions with at least slightly different
API's and where apr-util helps us to write programs that are independent of these
So yes having an apr-util API layer on top of serf would only make sense if we would
like to give the user a choice of different libraries that implement that apr-util



View raw message