tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Tomcat 6.0.18/ IIS 6.0 /SSL
Date Thu, 05 Aug 2010 22:20:00 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message