Add a servlet filter that does the reverse proxy work in translating html and javascript urls to the proxy based ones
---------------------------------------------------------------------------------------------------------------------
Key: GEOS-1918
URL: http://jira.codehaus.org/browse/GEOS-1918
Project: GeoServer
Issue Type: Improvement
Components: Configuration
Affects Versions: 1.6.3
Reporter: Gabriel Roldán
Assignee: Gabriel Roldán
Fix For: 1.6.4, 1.7.0-beta1
Up until fixing GEOS-1655, all the ui code where replacing the request URIs by the proxyfied version for html links and javascript/css code.
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).
Yet, fixing 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
- is configurable providing an all or nothing solution. It can either be enabled and thus all html, javascript and css urls will be proxified, or it could be disabled and thus no translation is made, implying the UI can only be accessed through the "intranet"
- 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira