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.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
