*.do
.
Note that the RewriteRule directives are kept as simple as possible, but in practice can contain regular expressions and backreferences to alter an entire class of URIs.
*.do
, so we need to alter the URI to include so the plug-in will recognize and handle the request.
WebSphere Resource | Link in HTML |
---|---|
/servlet/members/ProjectA/V3/SignIn.do | /ProjectA/SignIn |
The link as written won't be recognized by the WebSphere plug-in, and consequently has no hope of getting passed to WebSphere Application Server, so we add the following configuration:
RewriteEngine on
RewriteRule /ProjectA/SignIn /servlet/members/ProjectA/V3/SignIn.do [PT]
The PT flag is required, as this is what lets the WebSphere plug-in observe the results of the mod_rewrite processing.
The Alias directive isn't effective here, because that only maps a URI to a filename on the IHS system and doesn't change the URI in the request. If it was used, IHS would be trying to find /servlet/members/ProjectA/V3/SignIn.do under the Document Root.
*.do
pattern, but should be served as a static file. Because it's a URI already known to the outside world, he has to make some provision to ensure it's not passed to WebSphere.
Filesystem Resource | Link in HTML |
---|---|
htdocs/scooby_do.jpg | /scooby.do |
This link as written will be recognized by the WebSphere plug-in and passed to WebSphere Application Server, so we add the following directives to the IHS configuration to make sure it's served out of the filesystem:
RewriteEngine on
RewriteRule /scooby.do scooby_do.jpg [PT]
The PT flag is required, as this is what lets the WebSphere plug-in observe the results of the mod_rewrite processing.
The Alias directive is not effective here, because that only maps a URI to a filename on the IHS system and doesn't change the URI in the request.
During request processing, the plug-in will have no interest in the new URI of scooby_do.jpg.
The Redirect directive would be effective here, which is somewhat slower but updates the users browser with the proper URI
Redirect /scooby.do /scooby_do.jpg
WebSphere Resource | Typo |
---|---|
/servlet/already.do | /servlet/allready.do |
We change the URI that will be seen by the WebSphere plug-in as follows:
RewriteEngine on RewriteRule /servlet/allready.do /servlet/already.do [PT]
The PT flag is required, as this is what lets the WebSphere plug-in observe the results of the mod_rewrite processing.
The Alias directive is not effective here, because that only maps a URI to a filename on the IHS system and doesn't change the URI in the request. This would cause the WebSphere plug-in to handle the request but still operate on the original URI.
The Redirect directive would be effective here, which is somewhat slower but updates the users browser with the proper URI
Redirect /servlet/allready.do /servlet/already.do
One motivation for this aside from freeing up WebSphere threads is that only URLs served out of the IHS filesystem can be protected with .htaccess files, WebSphere resources must be protected with <Location> containers explicitly in httpd.conf.
The WAR file has been pushed to the IHS server in the /tmp directory.
The original access log entry which shows the plug-in handling the response: 127.0.0.1 - (mod_was_ap20_http.c/-2/handler) - [01/Dec/2006:14:57:51 -0500] "GET /SillyNew/theme/blue.css HTTP/1.1" 200 9049 After enabling config change as illustrated above, IHS has attempted to serve the file from its own filesystem: 127.0.0.1 - (mod_auth.c/401/check_user_id) - [01/Dec/2006:15:10:13 -0500] "GET /SillyNew/theme/blue.css HTTP/1.0" 401 466 After enabling above and sending the proper userid/password 127.0.0.1 - (core.c/0/handler) user1 [01/Dec/2006:15:11:15 -0500] "GET /SillyNew/theme/blue.css HTTP/1.0" 200 9049
RequestHeader
directive to change the Host headerRequestHeader
directive cannot effectively be used to influence the plug-in while it's deciding whether or not to handle the request, because the plug-in has completed this processing before RequestHeader
takes effect.
In the case that a request is going to be routed to the plug-in initially, RequestHeader
can be used to change the Host: header passed on by the plug-in to the Application Server.
.htaccess files are only processed by IHS after a request has been mapped to a local file, therefore .htaccess files cannot be the mechanism used to prevent the plug-in from handling a URL.
In some more complicated configurations, multiple mod_rewrite rules may potentially operate on the same incoming URL. In addition to the PassThrough flag (PT), the Last (L) flag is often used to end rewriting with the current rule. Flags are combined by separating them with commas as in the following:
# Transparently rewrite anything matching *.do under /servlet/app1 and stop rewrite processing (L=Last flag) RewriteRule /servlet/app1/(.*\.do) /servlet/$1.jsp [PT,L] RewriteRule ...
It's not possible to use mod_dir to to map e.g. / to /index.jsp because of checking done by mod_dir
when querying the DirectoryIndex
filenames through an internal subrequest.
The WebSphere Plugin will only a handle a request if it knows about the URL, hostname, and port. Typically the hostname (Host Aliases in the WebSphere Administration Console) is a wildcard, and the ports include all ports the frontend webserver is listening on.
If the WebSphere plugin is responding to /*, and you want the file to not be served by the WebSphere Plugin, you can configure IHS to proxy the request to a port on the same webserver that the WebSphere Plugin isn't handling.
This can be accomplished in a few steps:
Determine the new port, for which no Host Alias exists (e.g. 12345)
Configure IHS to listen on this new port, by adding a Listen directive
Create a new VirtualHost to handle the traffic for this port:
Listen 0.0.0.0:12345 <virtualhost *:12345> ServerName www.example.com # Static files are directly under this document root. DocumentRoot /path/to/staticContent.war/ </virtualhost>
If your current httpd.conf contains no Virtual Hosts, create a new Virtual Host
to capture the traffic coming from your browsers. Typically this incoming traffic is for port 80, which
is encoded in the VirtualHost
directive:
<virtualhost *:80> ServerName www.example.com DocumentRoot /opt/IBM/HTTPServer/htdocs/en_US/ </virtualhost>
If your config already has an explicit Virtual Host for your browser traffic, select this context for the next step
Identify the set of URL's that you want to transparently proxy using a perl-compatible regular expression. The criteria that is available could be context roots, file extensions, or a runtime test to see if the file exists on the IHS filesystem.
All URLS:
RewriteRule ^/(.*) ...
All URLs under /app1/ context root:
RewriteRule ... ^/app1/(.*)
All URL's with the listed extensions:
RewriteRule ... ^/(.*\.(?:gif|jpg|css|js))$
Match anything except the listed extensions, but %{REQUEST_URI} must be used later instead of $1 due to the negation character.
! \.(jsp|do)$
Note that only the component captured between the parenthesis is available as $1
in the replacement
URL (URL on the proxy server). %{REQUEST_URI} can be used to access the original requested URI.
Use mod_rewrite to proxy from the original URL to the new URL on the high port, optionally using the existence of the files in the IHS filesystem as a criteria. This configuration is on your port 80 (frontend) virtual host.
<virtualhost *:12345> ServerName www.example.com DocumentRoot /path/to/staticContent.war/ RewriteEngine on # These conditions prevent the URL from being proxied unless they actually exist in the IHS filesystem RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_URI} -f [OR] RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_URI} -d # If it exists in IHS, proxy it through the port that is ignored by the WebSphere Plugin RewriteRule ^/(.*) http://www.example.com:12345/$1 [P] ## Another example, proxy "/" only ## RewriteRule ^/$ http://www.example.com:12345/ [P] # Translate www.example.com:12345 to the external address for redirects ProxyPassReverse / http://www.example.com:12345/ </virtualhost>
Note the use of ProxyPassReverse
along with each RewriteRule
that is used to proxy, or Redirects may send the new port number out
to the browser URL bar.
Debugging tips:
Uncomment the LoadModule directive for mod_status, and add %{RH}e to your LogFormat directives to show which module is handling a request
If there are unexpected redirects, add %{Location}o to your LogFormat directives.
Configure RewriteLog and RewriteLogLevel 9 to debug your regular expression matching.
There may be some configurations which exploit this behavior to serve things such as images out of the filesystem instead of from WebSphere using an Alias directive -- upgraders will find they must replace this Alias directive with an equivalent RewriteRule directive.
Incorrect: Alias /servlet/images/ /images/ Correct : RewriteRule /servlet/images/(.*) /images/$1 [PT]