The manager application seems to be using absolute URLs on its pages for internal references. For instance, if deployed with a context-path of /manager, all images and hyperlinks in /manager/html are prefixed with /manager. This can be a problem if Tomcat is running behind a proxy. The following httpd config, for example, breaks the links: ProxyPass /some/other/path/ http://localhost:8080/manager/
If a proxy modifies the context path of a web application then it is the proxy's responsibility to clean up the mess (cookie paths, redirects, links in pages, anywhere else the path might appear) that results.
Why is it the admin's responsibility? The developer initiated the mess by making a faulty assumption.
The developer is doing exactly what they should do - using request.getContextPath() to correctly construct the URL. The breakage occurs in the proxy because the proxy is changing the path and the application has no way of knowing the path has been changed. Changing the context path in the proxy is something pretty much guaranteed to break all but the most trivial of web applications. If an sys admin decides to change the path in the proxy then they need to change it for both inbound and outbound traffic. The simplest solution is to change the context path in the back-end server to match the context path used by the proxy. In your example renaming $CATALINA_BASE/webapps/manager to $CATALINA_BASE/webapps/some#other#path is the change required. The complex solution is to use mod_proxy, mod_headers and mod_substitute (or equivalent) to fix the headers and the content. If the manager app generates URLs that start with "/manager" when deployed under a different path that would be a valid bug.
Having reviewed the source I think I see the problem. As a general rule, developers should NOT be using request.getContextPath() as you suggest. That just binds application content to a deployment-time concern. In this particular instance, however, the manager application appears to be a quick-and-dirty implementation with no separation of concerns. It's generating HTML in-code of all things. Given that approach, producing relative URLs is not likely to be trivial. Sorry for wasting your time.
The Manager app is certainly not a model application in many respects but it does get the handling of the context path right. Consider session cookies. The application is required to set the cookie path. That is set to the context path. If a proxy changes the the context path neither the application nor the container has any visibility that the path has changed. However for correct, secure operation the session cookie path needs to be changed to match the context path set in the proxy. The only component with the knowledge that the session cookie path needs to be changed and the knowledge of what it needs to be changed to is the proxy. The proxy changes the path and it has to take responsibility for the knock-on effects of that. 302 redirects are another example. The location header is required to be an absolute URI. Again, the proxy is the only place with the knowledge that this needs to be changed and what it should be changed to. Various popular libraries also set custom http headers that include absolute URIs. These too need to be changed. Again, the proxy is the only place that this can be done. Applications should be (and it is treated as a bug if any of the Tomcat provided apps are not) agnostic to the context path they are deployed to in the container. Applications can not be agnostic to changes in the context path introduced by a proxy. Cookie paths and location headers for 302 redirects to are some of the many things that make this impossible. Changing the context path in the proxy is rarely trivial. The more complex the application, the more complex the process of ensuring that it works correctly. By far the simplest approach is to change the context path in the container to match the path used by the proxy.
Cookies and redirects are easy with the directives provided by mod_proxy. At issue is HTML content. I see no reason why an application should, as a matter of general practice, bake the context-path into internal references. /manager/html, for example, has a link that reads /manager/images/asf-logo.gif when it could read images/asf-logo.gif. Granted, given the particular architecture that's not necessarily easy to do, but in other cases it is.
(In reply to Milo Hyson from comment #4) > As a general rule, developers should NOT be using request.getContextPath() as you suggest. I disagree. Relative links fail in all sorts of bad ways, which is why all JSP tag libraries, tools, etc. automatically insert the context-path at the beginning of all their URLs /by default/. It's not even clear to me that you can disable this kind of thing in JSTL for example. > That just binds application content to a deployment-time concern. Again, I disagree: in fact it frees the application from deployment-time concerns. If you re-name the context, the web application continues to work properly. If the page you are accessing was due to a "forward", the links continue to work even if the browser's URL resolution would otherwise create bad links. > Given [this] approach, producing relative URLs is not likely to be trivial. It would be trivial yet irrelevant. If you want to use a different context-path, don't play proxying games: just rename the context so it has the deployment path you want it to have.
(In reply to Christopher Schultz from comment #7) > Relative links fail in all sorts of bad ways ... Maybe I've just been lucky, but I've been using relative links in applications for years with no issue. Can you elaborate on these bad ways?
(In reply to Milo Hyson from comment #8) > Maybe I've just been lucky, but I've been using relative links in > applications for years with no issue. Can you elaborate on these bad ways? Here's a start: http://yoast.com/relative-urls-issues/
I came across that same article when I Googled the issue. The problem is it seems to be describing generally bad practices that are not specific to the use of relative URLs.
(In reply to Milo Hyson from comment #10) > I came across that same article when I Googled the issue. The problem is it > seems to be describing generally bad practices that are not specific to the > use of relative URLs. I'm sorry for launching a discussion in BZ. This really belongs on the users' list. I'd be happy to expand upon my assertions there.
(In reply to Christopher Schultz from comment #11) > I'm sorry for launching a discussion in BZ. This really belongs on the > users' list. I'd be happy to expand upon my assertions there. Please do. I'd like to know if I'm making a big mistake, and if so why it hasn't bitten me.
Note that some places (e.g. the 404 and 403 pages) respond to various URLs. It is so much easier and safer to use absolute URLs in all those responses. The "list" page is one of those places. That is what is shown by default regardless of what command was invoked on the Manager. If one wants to improve that, consider proposing a patch. Note that the manager application does not need to be named "manager". It can be deployed at some/other/path as easily and should work as well. mv manager some#other#path http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naming