httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <minf...@sharp.fm>
Subject Re: mod_serf is in trunk
Date Tue, 13 Nov 2007 10:27:52 GMT
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.

[1] Assuming it is actually smaller. The module is 440 lines + the size of
the serf library, while proxy is self contained.

> Oh yeah, and death to ProxyPass, ProxyPassMatch and all similar
> directives that should just go inside Location Blocks.  mod_serf will
> put everything inside a location block like this:
>
> <Location /foo>
>   SerfPass http://www.exmaple.com/
>   SerfPreseveHost On
>   SerfReversePass off
>   SerfTimeout 5
> </Location>
>
> So no more semi-global configurations options like mod_proxy has.

Proxy already supports this, which is no different:

<Location /foo>
  ProxyPass http://www.example.com/
  ProxyPassReverse http://www.example.com
</Location>

That said, a far deeper issue lies underneath the proxy, and that is:

"Why does the server treat Alias, ScriptAlias and ProxyPass as different
directives, when in reality they are all the same thing?"

Ideally at the core of http, there needs to be a generic way of mapping
URLs to other URLs, in such a way that functionality like load balancing
can be achieved easily and generically. The module mod_proxy (the parent
framework module) will then become part of the (http) core, and
mod_proxy_http and friends become just mod_http and friends.

In addition, I should be able to set access control for .htaccess as for
example allowing file:, but not allowing cgi:, or fastcgi:, or http:, or
ftp:.

But this is a goal that is most effectively tackled in amsterdam.

Regards,
Graham
--



Mime
View raw message