powered by Jive Software

Adding admin console configurable path

I have the need to use the admin console of a wildfire server that is located behind a firewall that only allows access to ports 80, 443 and 5223. Ports 80 and 443 are reserver for the web server (apache 2) and port 5223 is reserved for wildfire. The only way I have to access the wildfire admin console is to make it listen to address (localhost) and port 9090 and then use the apache proxy module to redirect like this:

I have tested it and it solves all my problems.

¿Do you think it is worth adding this to the code base?

Either that, or make a knowledge base out of the essence of your post. Perhaps even both. Other users might be running into similar problems.

I filed this as: JM-496

It seems like a pretty simple change, but the one thing I’‘m not sure about is if there’'s another possible fix. If we made links to resources differently, could that allow the proxy pass-thru without your workaround?



I could avoid the workaround if all the references to resources were relative and the transitions between JSP pages use the “jsp:forward” instead of “sendRedirect”, but this requires lot of changes, some of them non trivial.

The problem with references to resources is simple: the application generates HTML pages with absolute references like “/style/global.css”. These references can be changed to be relative like “style/global.css”, with no prefix.

The problems with the “sendRedirect” method is more complex. When you use this method the servlet container will send an HTTP response to the browser telling it to go to a new URL, for example, if you use code like this inside “page.jsp”:




The browser will send a request like this:

GET /page.jsp HTTP/1.1

Host: my_host

And it will receive a response like this:

HTTP/1.1 302 Moved Temporarily

Location: http://my_host/other_page.jsp

Then the browser will immediately fetch the new URL. This works fine when the host name and application path are the same from the point of view of the servlet container and from the point of view of the browser. This is not my case. This behavior can be avoided using “jsp:forward” instead of “sendRedirect”.