Original installation of Tomcat 5.5.x on Windows 2003 Server x32 with IIS6 Target Installation is Tomcat 5.5.x on Windows 2003 Server x64 with IIS6
Original installation has been working fine for some years but we're forced to migrate servers now as our host has become increasingly flaky. The original install is found at http://www.priestongroup.com where you may notice that as the site loads the url switches to http://www.priestongroup.com/app/public - this is due to the index file in the web root directory with some javascript that simply redirects to /app/public where Tomcat takes over. When the user select 'Login' from the above page the url switches to https://www.priestongroup.com/app/secure where a client or employee may login. If a client logs in they are presented with more Tomcat hosted pages with all sorts of pretty graphs and what-not, while if an employee logs in they are directed to the ASP portion of the site where all the administrative tools are housed. Target installation: Jakarta ISAPI_Redirector successfully installed and reporting 'green' under IIS web site properties - this required enabling 32 bit apps on Win64 by way of the command line since none of the 64bit dll's I tried ever worked. The uriworkermap.properties for Jakarta appears as follows: # uriworker.properties /app/*=ajp13w /dev/*=ajp13w2 And workers.properties looks like this: worker.list=ajp13w,ajp13w2 worker.ajp13w.type=ajp13 worker.ajp13w.host=174.123.91.100 worker.ajp13w.port=8009 worker.ajp13w2.type=ajp13 worker.ajp13w2.host=174.123.91.98 worker.ajp13w2.port=8009 I can only assume that ajp13w is the main site and judging by the server.xml that ajp13w2 is for the database connection. The server.xml file has the following definitions: <Server port="8005" shutdown="SHUTDOWN"> <GlobalNamingResources> <Resource name="jdbc/dbcp" auth="Container" type="javax.sql.DataSource" driverClassName="net.sourceforge.jtds.jdbc.Driver" factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory" url="jdbc:jtds:sqlserver://174.123.91.98:1433;SelectMethod=cursor" username="webuser" password="T3rminal7" maxActive="20" maxIdle="10" maxWait="10000" /> </GlobalNamingResources> <Service name="Catalina"> <Connector port="8080" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" /> <Connector port="8009" enableLookups="false" redirectPort="443" protocol="AJP/1.3" /> <Engine name="Catalina" defaultHost="localhost"> <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false"> </Host> </Engine> </Service> </Server> Unlike the original site that works, attempting to go directly to the new location via IP results in a 404, though you might notice that the url has had /app/public appended to it indicating that the index.html file with the javascript redirector did in fact execute but for some reason Tomcat didn't supply a page. If you tack port 8080 onto the url (http://174.123.91.100:8080) you receive a blank page since we've swapped out the original tomcat welcome page with a blank placeholder in order to create some semblance of security. If we go a step further and use the full url of http://175.123.91.100:8080/app/public we actually find that Tomcat returns the expected page. The question is why doesn't it do it to begin with when the user was redirected by the javascript? The last part of the problem has to do with SSL in that when you click on the login link from the above working url (http://175.123.91.100:8080/app/public) instead of getting the login page you get a 'couldn't connect' type of error and you can see that the url has changed to https://175.123.91.100:8443/app/secure - though this is the correct location for the login page the request isn't being processed for some reason. >From reading the Apache Tomcat SSL documentation it appears that when running Tomcat on top of IIS the default behavior is to use the IIS built in SSL functionality. With that in mind I went ahead and installed the security certificate from our original server onto the new server but doing so had no effect on the above problem. Thanks in advance for any input on this mysterious behavior! Rafe Magnuson --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
