how to handle requests to www.domain.com (no context path) w/ISAPI redirector and IIS?

[Jeff <li...@skubick.com>]

I've gotten to the point where I can have requests sent to IIS at
http://anysiteonwin2kmachine.mydomain.com/specific_context_path 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/firstcontextpath
http://www.iis.virtual.host/*.jsp=http://tomcat.virtual.host/firstcontextpat
h
http://iis.virtual.host/servlet/*=http://tomcat.virtual.host/servlet
http://www.iis.virtual.host/servlet/*=http://tomcat.virtual.host/servlet
http://iis.virtual.host/somecontext/*=http://tomcat.virtual.host/differentco
ntext
http://www.iis.virtual.host/somecontext/*=http://tomcat.virtual.host/differe
ntcontext

with other IIS virtual hosts corresponding to different tomcat virtual
hosts:
http://another.virtual.host/*.jsp=http://different.tomcat.virtualhost/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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>