On Nov 13, 2007 6:06 AM, Plüm, Rüdiger, VF-Group <[EMAIL PROTECTED]> 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
