I got the impression it matters from the "the current proxification..." statement. Given I was wrong and I don't want to slow you down, can you just add a jira for me to "make sure reverse proxy filter uses RequestUtil.buildURL properly" or alike?
Cheers, Gabriel Andrea Aime wrote: > Gabriel Roldan ha scritto: >> replying to this thread as it's the one designated for feedback. >> >> First, the minimalist and naive one: use StringBuilder instead of >> StringBuffer for a little extra speed :) > > Well, I really want to see if this is any measurable in our requests ;-) > >> Then the one I've been thinking about: >> stating that "The current "proxification" mechanism will be a a >> URLMangler changing only the baseURL." may be oversimplistic. That >> will only work for URL's programatically created, but the current >> proxification deals with those that are not. > > The GSIP is only about those programmatically build, for the > responses. I did not envison any relationship with the proxy filter. > Not sure where you got the impression is what otherwise. > > I think Sampo does not really need the UI to be handled, > he's interested in keeping standard WMS/WFS clients working > in face of their custom authentication. > >> What ReverseProxyFilter does can basically be reduced to a two-step >> process, for each line of filtered content (html, css, javascript, etc): >> >> translatedLine = translatedLine.replaceAll(serverBase, proxyBase); >> translatedLine = translatedLine.replaceAll(context, proxyContext); >> >> It is not like for each URL found it's calling RequestUtils, and I >> think doing so to call RequestUtils.buildURL _may_ be overkiller. More >> over, I'm not sure it'll work since much of them lack base/context and >> are only <path>?<params> >> >> What I've been trying to figure out is how much of >> ReverseProxyFilter's functionality could be abstracted out to this >> URLMangler. >> >> The reverse proxy does only care about base and context. Currently it >> has effect only over two aspects of URLs: base (protocol, server, >> port) and context (like in servlet context for the web app). >> >> With this new callbacks it'll need to take care also of path and >> params, so it can change "../wms?request=GetCapabilities? into >> "../wms?request=GetCapabilities&myCustomToken=something" >> >> Calling RequestUtils.buildURL for each and every URL found in >> html/js/css resources may require a smarter, more structured (and >> slow) parsing of the content in order to actually extract the URL's >> instead of a simple String.replaceAll... So I guess we'll end up >> calling RequestUtils.buildURL(GeoServer.getProxyBaseUrl()) as it's >> being done right now and then extend the servlet filter so it appends >> also any extra CGI parameters added by the callbacks? > > Hmmm... actually the manglers can do what they please with all parts > of the URL (that's why there are the string buffers) and the KVP . > So if you want to fall back on them I think you have to make a full > parse of each URL. > Wondering, can't you get the base url by getting somewhere the host, > port and application base path? I think we did something like that > in 1.7.x somewhere. > > Anyways, I'm not fully convinced the two systems should share any code. > > Cheers > Andrea > > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
