Wednesday 4 November 2009

Virtual Host matching

Ran into another issue last week although this was easy to work around it was a bit of an annoyance.

A user was hitting our Load Balancer on port 8080 which we could then see this being forwarded onto our HTTP Server on port 8080 as well, but by the time this request got through to the WAS plugin, the plugin was trying to match it to en entry with port 80 which didn't exist in our plugin so the request failed.

For some reason the header was being updated by our LB, although I could just add port 80 to the vhost entry so that the plugin forwarded the reuqest onto WAS, I was keen to figure out what was going on and if there was any other way around this.

Our LB team provided little help, but the guys at IBM pointed me at the "Virtual host matching" setting in the plugin properties screen which maps to the VHostMatchingCompat setting in the plugin.

From the info center:

"By default, this field is not checked, and matching is done logically using the port number contained in the host header. Select this field if you want virtual host mapping performed by physically using the port number for which the request was received."

I checked this field, redployed the plugin and now the plugin would try to match on port 8080 (the port the request actualy came in on) rather than port 80 which was in the header.


No comments:

Post a Comment