httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VF-Group <>
Subject Re: mod_serf is in trunk
Date Tue, 13 Nov 2007 11:06:16 GMT

> -----Ursprüngliche Nachricht-----
> Von: Graham Leggett 
> Gesendet: Dienstag, 13. November 2007 11:28
> An:
> Cc:
> Betreff: Re: mod_serf is in trunk
> On Tue, November 13, 2007 6:34 am, Paul Querna wrote:
> > I've added mod_serf in r594425:
> >
> >
> > I've grown exceptionally... tired of looking at mod_proxy.  
> mod_serf is
> > nice and tight at 440 lines or so.
> >
> > With just a little more work, I think it could be a production level
> > reverse proxy.
> I am not sure I follow the reasoning here.
> mod_proxy is a pluggable framework, and as such offers significant
> flexibility, which is why we have mod_proxy_http, mod_proxy_ftp,
> mod_proxy_connect, mod_proxy_ajp and mod_proxy_balancer 
> modules, that the
> end user is free to use or not use these modules as needed. 
> All of these
> modules exist because end users actively use this functionality.
> mod_serf, as I can see so far, is a simple module, offers 
> reverse proxy
> http only, and is smaller[1] than mod_proxy only because it does less.
> Assuming of course the issue of the missing documentation is fixed, I
> don't see how continued development on mod_serf could bring 
> us to anything
> other than what we have now, only written differently.
> Now, say mod_serf gets documented properly and finds itself 
> in a release.
> How do you answer the following end user questions?
> "There are two reverse proxy modules in httpd, which should I 
> use and why?"
> "Does this mean you are taking AJP (etc) out of the server?"
> The answers "the code is tighter" and "I am tired of looking 
> at the code"
> answer none of these end user questions, so I am -1 on this 
> until I see a
> proper justification for the new module.

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.
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.



View raw message