[
http://jira.codehaus.org/browse/GEOS-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Caradoc-Davies reopened GEOS-1918:
--------------------------------------
This changes breaks the build (see GEOS-1921). Are the unit tests still run
even when the filter is disabled, as it is by default?
> 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
