httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Erenkrantz" <jus...@erenkrantz.com>
Subject Re: mod_serf is in trunk
Date Tue, 13 Nov 2007 15:39:08 GMT
On Nov 13, 2007 6:06 AM, Plüm, Rüdiger, VF-Group
<ruediger.pluem@vodafone.com> 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.).

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.

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

> 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

Mime
View raw message