Remy Maucherat wrote:
Jess Holle wrote:
One issue here:
When Apache and Tomcat are used together via AJP13:
1. The host, port, protocol, etc, are exactly that at the Apache
level, i.e. one's web app sees Apache and Tomcat as 1 entity. This is a very good thing overall compared to reverse proxying (if
that's the mod_proxy proposal).
I have no idea how to get around that ;) This seems a showstopper: the user will have to read the connector's documentation.
Certainly things function in a reverse proxy environment and so the more complex situation is handled. The issue is that individual developers *can* do bad things by assuming that the request protocol is that they should use in <base> tags, etc.
Overall, that would just be life, though and is insufficient reason not to leverage mod_proxy.
2. The body content, query string, etc, are reported to one's web
application precisely as sent, whereas Tomcat pre-processes them a
bit more than picky, low-level request parsing code can accept. [Yes, the "picky" code is *too* picky, but it isn't mine :-)]
I have no idea what your webapp is doing, but it's not portable. All the trasformations done respect the HTTP and servlet specifications.
Actually it is rather portable and does not break any spec to the best of my knowledge. It just assumes it can get at the original content body stream, request string, etc, as an alternative to getParameter() without missing anything. Why this is the case is a long story. I also miss forget exactly where things fall down, but Apache, iPlanet (with embedded servlet engine), and IIS (with Tomcat) all work (except config issues with IIS 6...)
This appears to be far removed from most folks' experience, so I guess Tomcat's httpd is good enough for most.
-- Jess Holle
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
