Up until fixing
Problem was it didn't work for proxy url's that replace the /geoserver context. That is, only the protocol, server and port were respected, among being the wrong way to handle URL translation, as it could be done by an external reverse proxy (as apache's mod_html).
GEOS-1655 meant a regression. For the most simple case, as stated above, the replacement of protocol://host:port just worked, as long as /geoserver were the context path both at the servlet container and the proxy.
This task aims at fixing that regression as well as to provide a clean, single entry point, for a reverse proxy like content replacement that:
- is implemented as a servlet filter, translating the URLs in the output content, replacing them by the proxified version
- the mime types for the proxified contents are configurable as a filter init parameter, using regular expressions
- not only protocol://host:port can be translated, but also an arbitrary context path, like using /geoserver/tools as the proxy entry point instead of the /geoserver servlet context
This way, the clear separation of concerns between UI code and reverse proxy remains and it could be reused out of the box no matter what UI technology is used in the future.
For the people not able to configure the proxy externally (like the ones using apache 1 instead of apache 2, for which mod_html is not available), there's an easy option to still be able of publishing the geoserver configuration ui through the proxy server.