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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
