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 -- Andrea Aime 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
