Maybe to avoid further meandering in what should or should not work, here is a short
tutorial of how all this stuff works.
At the end of the chain, you have a Tomcat Engine. This engine processes HTTP requests
which it receives in some internal Tomcat format. The requests are processed by
forwarding them to "web applications" within Tomcat, who process the request and generate
a response.
On top of the Tomcat engine are sitting one or more <Connector>'s.
Each of these Connector's is at the same time a TCP socket listening on some port, and a
sophisticated translation engine. Each Connector translates the requests received on its
port, from the external communications protocol format used (e.g. HTTP or HTTPS or AJP)
into the common internal Tomcat request format, and then passes it to the Tomcat engine.
Graphically, it looks like this :
Connector 1 Connector 2 Connector 3
HTTP AJP HTTPS
\ | /
Tomcat engine
/ | \
webapp1 webapp2 webapp3
You can send a request (using the appropriate format) through any of the enabled
Connector's. For Tomcat in the end it does not matter. It will send the response via the
same Connector, which will perform the appropriate reverse translation according to its
protocol.
Now imagine a front-end server, like IIS.
For reasons of your own, you want to send the request to IIS first, and would like IIS to
determine if this request is to handle locally by itself, or to be forwarded to a back-end
Tomcat, and to do that if needed.
That is where the IIS add-on module isapi_redirect comes into play.
IIS gives it the URL of a request just received. isapi_redirect, in function of its
configuration, decides if this request is for a back-end Tomcat or not.
(That is what uriworkermap helps in doing).
If it decides that this URL is not for Tomcat, it returns to IIS saying "sorry, not for
me", and IIS looks for other ways to satisfy this request.
If isapi_redirect decides that this request is for a back-end Tomcat, then it checks for
which one. For isapi_redirect, each back-end Tomcat to which it can redirect requests is
called a "worker". (In a simple case, there is only one.).
(Here is where the workers.properties settings matter)
When isapi_redirect has determined to which "worker" it should pass the request, it tries
to set up a TCP channel with this worker (Tomcat), on a port which understands the AJP
protocol (aka, an AJP Connector of that Tomcat).
If this does not work (because the worker is not configured properly or the corresponding
Tomcat is simply not running), isapi_redirect will return an error to IIS.
If it works, then isapi_redirect encodes the request according to the requirements of the
AJP protocol, and sends it to Tomcat through this TCP channel.
isapi_redirect then waits for the response, on the same TCP channel.
When it gets the response, it returns it to IIS, which returns it to the
browser.
So the full graphic now looks like this :
browser
|
TCP channel (SSL/HTTPS)
|
IIS
|
isapi_redirector
|
TCP channel (non-SSL)
|
Connector 1 Connector 2 Connector 3
HTTP AJP HTTPS
\ | /
Tomcat engine
/ | \
webapp1 webapp2 webapp3
Of course, Tomcat can deal with HTTPS all on its own, so you do not necessarily need an
IIS in front for that. You could also have the browsers use HTTPS to talk directly to Tomcat.
Then the configuration would be this :
browser
|
TCP channel (SSL/HTTPS)
|
Connector 1 Connector 2 Connector 3
HTTP AJP HTTPS
\ | /
Tomcat engine
/ | \
webapp1 webapp2 webapp3
and as far as Tomcat is concerned, it will not make much difference (except that now the
Tomcat HTTPS Connector will be doing more work, and the AJP Connector less work).
There are good reasons to use a front-end Apache httpd, or IIS, in front of
Tomcat.
There are also bad reasons, such as a simple lack of information.
If your only reason to put IIS/isapi_redirect in front of Tomcat is to handle HTTPS
connections, then it is not a very good reason, and it makes the setup more complicated
than it could be.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
