tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reynir Hübner <rey...@hugsmidjan.is>
Subject RE: how to handle requests to www.domain.com (no context path) w/ISAPI redirector and IIS?
Date Sun, 22 Sep 2002 20:44:11 GMT
hi, 
you will have to create a virtual host in IIS, and install the ISAPI redirector in that host
to redirect to a host installed in tomcat.
in other words, if you have a virtual host configured in tomcat with by the name host.domain.com
you must have a virtual host with the same hostmark in IIS, with the isapi_redirect filter
installed.

To enable the default.jsp or index.jsp you must have a default.asp page in the folder that
makes a serverside redirect to index.jsp, as to be able to map the IISredirect url (in uriworkermap.properties)
you must have a file ending .jsp, if you set index.jsp as a default document in IIs the ending
does not get resolved in the URL and the request is not redirected.


hope it helps,
-reynir@hugsmidjan.is


> -----Original Message-----
> From: Jeff [mailto:lists@skubick.com]
> Sent: 22. september 2002 19:13
> To: tomcat-user@jakarta.apache.org
> Subject: how to handle requests to www.domain.com (no context path)
> w/ISAPI redirector and IIS?
> 
> 
> I've gotten to the point where I can have requests sent to IIS at
> http://anysiteonwin2kmachine.mydomain.com/specific_context_pat
> h handled by
> the webapp whose context path is /specific_context_path , but 
> I'm at a loss
> as to how requests to a site's default page (index.jsp) 
> should be set up
> among multiple different virtual IIS hosts. In other words, 
> how to handle
> requests to http://specificvirtualsiteonwin2kmachine.mydomain.com or
> http://differentvirtualsiteonwin2kmachine.anotherdomain.com 
> that implicitly
> map to index.jsp in the site's root directory and get IIS to 
> let Tomcat
> handle them.
> 
> The main problem I'm seeing is that the whole ISAPI 
> redirector mechanism
> seems to have no concept of virtual hosts, nor does it seem 
> to have any
> mechanism for handling requests that don't involve a 
> recognizable context
> path as part of the request sent to IIS.
> 
> in other words, I can set up uriworkermap.properties with:
> 
> /context1=$(default_worker)
> /context1/*=$(default_worker)
> /context2=$(default_worker)
> /context2/*=$(default_worker)
> 
> and have requests sent to
> http://irrelevant_hostname.resolving_to_server_ip.net/context1
>  handled by
> the webapp whose context path is /context1, and have requests sent to
> http://irrelevant_hostname.resolving_to_server_ip.net/context2
>  handled by
> the webapp whose context path is /context2, but I see no 
> straightforward way
> to have requests made to 
> http://specific_site.hosted_on_myserver.com return
> one default jsp file associated with /context1 and have 
> requests made to
> http://different_site.hosted_on_myserver.net return a 
> (different) jsp file
> associated with /context2.
> 
> even if adding
> 
> /*.jsp=$(default_worker)
> 
> to uriworkermap.properties worked (it didn't), there is still 
> no apparent
> mechanism to associate *.jsp for one site with 
> /context1/*.jsp and *.jsp for
> another site with /context2/*.jsp
> 
> What seems to be missing is a mechanism to tell the ISAPI redirector,
> "requests made to http://firsthost/*.jsp should be proxied 
> over to Tomcat as
> though they were really made to 
> http://firsthost/context1/*.jsp", "requests
> made to http://secondhost/*.jsp should be proxied over to 
> Tomcat as though
> they were really made to http://secondhost/context2/*.jsp" (with each
> handled by a separate Tomcat virtual host), with the existing 
> uriworkermap
> scheme simply ADDING context paths to specific IIS virtual 
> sites indicating
> requests that should simply be proxied over to Tomcat 
> unchanged, like in
> this hypothetical properties file I'm envisioning:
> 
> http://iis.virtual.host/*.jsp=http://tomcat.virtual.host/first
> contextpath
> http://www.iis.virtual.host/*.jsp=http://tomcat.virtual.host/f
> irstcontextpat
> h
> http://iis.virtual.host/servlet/*=http://tomcat.virtual.host/servlet
> http://www.iis.virtual.host/servlet/*=http://tomcat.virtual.ho
> st/servlet
> http://iis.virtual.host/somecontext/*=http://tomcat.virtual.ho
> st/differentco
> ntext
> http://www.iis.virtual.host/somecontext/*=http://tomcat.virtua
> l.host/differe
> ntcontext
> 
> with other IIS virtual hosts corresponding to different tomcat virtual
> hosts:
> http://another.virtual.host/*.jsp=http://different.tomcat.virt
ualhost/its_co
ntextpath
http://another.virtual.host/struts/*=http://different.tomcat.virtualhost/str
uts

etc.

In other words, providing a mechanism to identify requests that IIS needs to
let Tomcat handle, but give Tomcat (or the redirector) enough information to
intelligently handle requests that make sense to IIS, but not to Tomcat
(without a little rewriting first).

Actually, such a scheme is more or less how I kludged Apache to handle a
similar situation a few months ago (when mod_jk was missing a feature I
needed, and mod_webapp wasn't quite ready for real use) using mod_rewrite to
proxy requests from Apache to Tomcat at port 8080 (dispensing with ajp
altogether). It was ugly and inefficient, but it made the sites work and
kept my boss happy...

Am I overlooking an obvious solution, or is there really no good way to have
Tomcat handle requests to a specific IIS virtual site's default index.jsp
file, or to differentiate among virtual hosts at the Tomcat level as well as
at the IIS level. Actually, if the scheme I mentioned above permitted
context path substitution (so the Tomcat context path had no necessary path
similarity to the request made to IIS), virtual hosts at the Tomcat level
would be nice, but not necessary (http://first.com/servlet could be sent to
Tomcat as http://localhost/first, http://second.com/servlet could be sent to
Tomcat as http://localhost/second, etc.)



--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message