httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: Invitation to HTTPD commiters in tomcat-dev
Date Wed, 21 Jul 2004 11:52:26 GMT
Mladen Turk wrote:

>>I think it's very necessary - sharing those common concepts 
>>ultimately makes for doing things in a consistent way. It 
>>makes a big difference to the usability of httpd.

> I'm sure that the 'normalization' would lead to nowhere.

I don't follow - what does "normalisation would lead to nowhere" mean?

> HTTP is a statles protocol, and our concept is to have a constant connection
> pool to the well known application server.
> So, unlike HTTP protocol we are embedding the remote application server, and
> it just happens that we are doing it using the same TCP/IP protocol for
> that.

You are missing the purpose of mod_proxy. It is not an HTTP proxy only, 
but a general protocol proxy that can support both stateless and 
stateful backends.

Proxy supports HTTP keepalives (via a mechanism that can be extended 
into a full pool), and it supports FTP (a stateful protocol). There is 
no reason why proxy could not support another stateful protocol like AJP.

If httpd is to support another backend protocol, then the proxy 
frameowrk is the place to do it.

> Quite contraty, this is the main reason. We already have jk2 that can be
> used even for proxying HTTP requests. Are you wiling to write the http
> protocol for mod_jk2?

Considering that httpd already has a framework to connect to various 
backend protocols (proxy and friends), and already has an established 
syntax within httpd, I don't see any point in replacing it with another 
external module like the existing mod_jk2. Are you willing to write the 
ftp module for mod_jk2?

> Again, application server != http server.

Of course an http server is an application server.

> Agreed, pehaps some day they will convolve to the single module, but right
> now I don't see the point for it, especialy when the mod_proxy is well
> established module.

I think there is a fundamental misunderstanding as to the way proxy works.

mod_proxy is a framework - the module is not useful on it's own without 
helper modules plugged into the back of it. Right now, there are helper 
modules to support HTTP/1.1, FTP and HTTP/1.1's CONNECT method.

mod_proxy currently handles the connection to the backend, it then 
passes this connection to the protocol handler module for completion. 
This connection handling can easily be pulled out into a load balancing 
module, allowing connections to the backend to be reused for HTTP 
keepalives, FTP session continuation and a connection pool for AJP, or a 
proxy_sticky module, that is able to ensure the same requests go to the 
same server.

The bottom line is that httpd has an established framework for 
supporting backend application server protocols like HTTP, FTP, and now 
AJP. So far I have seen no technical justification whatsoever for 
putting an AJP protocol module outside of this framework.


View raw message