|
Home > Archive > WebSphere Application Server > January 2005 > Virtual Host mappings to http transports
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Virtual Host mappings to http transports
|
|
| alo30bb 2005-01-19, 7:48 am |
| Would anybody know what the relationship between Virtual Hosts and HTTP
Transports are?.
How does WebSphere 5.1 or 5.0 decide with transport to use.
If my HTTP Server listens on both 80 and 443, which transport will be used
9080 or 9443?
How does it match up?
How can I be sure the that the communication channel is ssl for all hops
443->9443 and not 443->9080.
| |
| Ken Hygh 2005-01-19, 7:48 am |
| alo30bb wrote:
>Would anybody know what the relationship between Virtual Hosts and HTTP
>Transports are?.
>
>How does WebSphere 5.1 or 5.0 decide with transport to use.
>
>If my HTTP Server listens on both 80 and 443, which transport will be used
>9080 or 9443?
>How does it match up?
>
>How can I be sure the that the communication channel is ssl for all hops
>443->9443 and not 443->9080.
>
>
>
>
There isn't a direct connection between the 2.
HTTP Transports are intended to be used for the communications links
between Web Servers and the Application Server. Virtual hosts are for
routing requests to the correct container/servlet. If a request comes in
to the web server and does not match one of WebSphere's virtual hosts,
the plugin ignores it and lets the web server handle the request. If the
request does match one of WAS's virtual hosts, then it uses the mapping
info (application X is mapped to virtual host Y) to know which container
to send the request to.
When a SSL request comes in to the HTTP server, it'll flow over an SSL
connection from the plugin to the app server:
http://publib.boulder.ibm.com/infoc...come_base.html,
so 443 -> 9443 and NOT 443->9080
That said, it's fairly common to set up a virtual host such that it will
serve requests that come direct to the webserver AND to WAS, at least in
test environments. You'd set up a virtual host for webserver:80,
webserver:443, wasserver:9080, and wasserver:9443.
Ken
| |
| alo30bb 2005-01-19, 5:54 pm |
| Ok,
However the server maps to the transport, and the web application maps and
http plug-in map to the virtual hosts. There is no direct mapping between
the virtual host and http transport.
Both contain a list of host and ports, I don't understand how the mapping
takes place.
"Ken Hygh" <kenhygh@nc.rr.com> wrote in message
news:cslnpr$3tpe$1@news.boulder.ibm.com...
> alo30bb wrote:
>
> There isn't a direct connection between the 2.
>
> HTTP Transports are intended to be used for the communications links
> between Web Servers and the Application Server. Virtual hosts are for
> routing requests to the correct container/servlet. If a request comes in
> to the web server and does not match one of WebSphere's virtual hosts, the
> plugin ignores it and lets the web server handle the request. If the
> request does match one of WAS's virtual hosts, then it uses the mapping
> info (application X is mapped to virtual host Y) to know which container
> to send the request to.
>
> When a SSL request comes in to the HTTP server, it'll flow over an SSL
> connection from the plugin to the app server:
> http://publib.boulder.ibm.com/infoc...come_base.html,
> so 443 -> 9443 and NOT 443->9080
>
> That said, it's fairly common to set up a virtual host such that it will
> serve requests that come direct to the webserver AND to WAS, at least in
> test environments. You'd set up a virtual host for webserver:80,
> webserver:443, wasserver:9080, and wasserver:9443.
>
> Ken
>
| |
| Ken Hygh 2005-01-19, 5:54 pm |
| alo30bb wrote:
>Ok,
>However the server maps to the transport, and the web application maps and
>http plug-in map to the virtual hosts. There is no direct mapping between
>the virtual host and http transport.
>Both contain a list of host and ports, I don't understand how the mapping
>takes place.
>
>
>
A Web Container has HTTP transports: the ports it's listening on,
typically one for HTTP and one for HTTPS.
A Virtual Host is typically a machine name & port number, though either
can be wildcarded.
When you install an application, you put it into a web container (or
more than one), and select a virtual host. Voila, you have a mapping.
An example might make this clearer:
Posit a configuration of 1 web server (mycompany.com), and a single app
server (wasserver), and the webserver is listening on several ports, for
both 'mycompany.com' and 'specials.mycompany.com'.
Let's say you have 2 web applications, one with a context root of '/',
and the other with a context root of '/myapp'.
You have 2 virtual hosts, one set to "*:80", and the other to
"mycompany.com:443".
Taking the simplest case, you have one WebSphere server named
'wasserver', with its web container listening for HTTP on port 9080, an
listening for HTTPS traffic on 9443.
Install WAR 1, '/', to virtual host 1 (*:80), and WAR 2, '/myapp', to
virtual host 2 (mycompany.com:443)
after the installation, regen the plugin configuration file, and put it
into the correct spot on the web server.
Remember that very Web request has a port number, though it may be
unstated and default to port 80 for http://xxx and 443 for https://xxx.
So, if you start a browser and point to
'http://mycompany.com/index.html', then the plugin will see a request
for "mycompany.com:80/index.html", find that this URL matches a rule for
WAR 1, find which transport to send that over, and forward the request
to the proper web container at the proper machine name and port, in this
case 'wasserver:9080'. The web container will get the request, and try
to serve index.html.
If you start a browser and point to
'http://mycompany.com:443/index.html' - the request will fail. There is
no webapp context root assigned to '/' for a request of
'mycompany.com:443/*', and WAS will fail the request.
If you start a browser and point to
'http://mycompany.com:443/myapp/index.html', then this URL will match a
rule for WAR 2, and the plugin will forward the request to the web
container at 'wasserver:9443' (the request came in over SSL, it gets
forwarded to the web container over SSL).
If a request comes in for 'https://specials.mycompany.com', then the
plugin will see that this request doesn't match any of its virtual host
rules, and pass the request back to the webserver, which may (or may
not) know what to do with this itself.
Most of this work is done in the webserver plugin - you can take a look
at plugin-cfg.xml, and deduce how this mapping is done.
whew, this turned into an epic, sorry.
Ken
|
|
|
|
|