Sometimes one want to change path components of the URLs under which an application
is available. Especially if a web application is deployed as some context, say /myapp,
marketing prefers short URLs, so want the application to be directly available under
http://www.mycompany.com/. Although you can deploy the application as the so-called
ROOT context, which will be directly available at "/", admins often prefer not to use
the ROOT context, e.g. because only one application can be the root context (per host).
The procedure to change the URLs in the reverse proxy is tedious, because often
an application produces self-referential URLs, which then include the path components
which you tried to hide to the outside world. Nevertheless, if you absolutely need to do it,
here are the steps.
Case A: You need to make the application available at a simple URL, but it is OK, if
users proceed using the more complex URLs, as long as they don't have to type them in.
That's the easy case, and if this suffices to you, you're lucky. Use a simply RedirectMatch
for the Apache HTTP Server:
RedirectMatch ^/$ http://www.mycompany.com/myapp/
Your application will then be available under http://www.mycompany.com/,
and each visitor will be immediately redirected to the real URL
http://www.mycompany.com/myapp/
Case B: You need to hide path components for all requests going to the application.
Here's the recipe for the case, where you want to hide the first path component
/myapp. More complex manipulations are left as an exercise to the reader.
First the solution for the case of the Apache HTTP Server:
1. Use mod_rewrite
to add /myapp to all requests before forwarding to the backend:
# Don't forget the PT flag! (pass through)
RewriteRule ^/(.*) http://www.mycompany.com/myapp/$1 [PT]
2. Use mod_headers
to rewrite any HTTP redirects your application might return. Such redirects typically contain
the path components you want to hide, because by the HTTP standard, redirects always need to include
the full URL, and your application is not aware of the fact, that your clients talk to it via
some shortened URL. An HTTP redirect is done with a special response header named Location.
We rewrite the Location headers of our responses:
# Keep protocol, server and port if present,
# but insert our webapp name before the rest of the URL
Header edit Location ^([^/]*//[^/]*)?/(.*)$ $1/myapp/$2
3. Use mod_headers again, to rewrite the paths contained in any cookies,
your application might set. Such cookie paths again might contain
the path components you want to hide.
A cookie is set with the HTTP response header named Set-Cookie.
We rewrite the Set-Cookie headers of our responses:
# Fix the cookie path
Header edit Set-Cookie "^(.*; Path=/)(.*)" $1/myapp/$2
3. Some applications might contain hard coded absolute links.
In this case check, whether you find a configuration item for your web framework
to configure the base URL. If not, your only chance is to parse all response
content bodies and do search and replace. This is fragile and very resource intensive.
If you really need to do this, you can use
mod_proxy_html,
mod_substitute
or mod_sed
for this task.
If you are using Microsoft IIS as a web server, the ISAPI redirector provides a way
of doing the first step with a builtin feature. You define a mapping file for simple prefix
changes like this:
# Add a context prefix to all requests ...
/=/myapp/
# ... or change some prefix ...
/oldapp/=/myapp/
and then put the name of the file in the rewrite_rule_file entry of the registry or your
isapi_redirect.properties file. In your uriworkermap.properties file, you
still need to map the URLs as they are before rewriting!
More complex rewrites can be done using the same file, but with regular expressions. A leading
tilde sign '~', indicates, that you are using a regular expression:
# Use a regular expression rewrite
~/oldapps([0-9]*)/=/newapps$1/
There is no support for Steps 2 (rewriting redirect responses) or 3 (rewriting cookie paths).
