> -----Ursprüngliche Nachricht----- > Von: Graham Leggett > Gesendet: Dienstag, 13. November 2007 11:28 > An: dev@httpd.apache.org > Cc: dev@httpd.apache.org > 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: > > http://svn.apache.org/viewvc?view=rev&revision=594425 > > > > 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. Regards Rüdiger
