On Monday, October 24, 2016 at 11:23:07 AM UTC+2, Jens wrote: > > Hmm generally I like having build-in proxy with GWT, as I usually use a > proxy anyways at work just to mimic the production behavior (load balancers > serving static GWT app files and proxy certain requests to servlet > container). However I think there should be more options to be more > configurable. >
I'd tend to disagree. > Looking at our setup I would instantly ask for cookie rewriting (multiple > ProxyPassReverseCookieDomain, ProxyPassReverseCookiePath), > Those cookies likely wouldn't "work" anyway as they wouldn't be shared with the other "subdomains" (unless your own machine shares the same parent-domain as your server, in which case you don't need to rewrite the cookies anyway). I believe that, similarly to those redirects where you need to generate a full URL (generally for SSO), your server should adapt its behavior depending on the Host or X-Forwarded-Host; either that or use another proxy that does the rewriting for you (most "dev proxies" don't: Webpack –unless you use your own middleware or onProxyRes event handler–, devd, mitmproxy, etc.) ProxyPathReverseCookiePath is useless: the reverse proxy doesn't rewrite paths (on purpose! the goal is only to be able to intercept some requests to route them to the CodeServer, or serve the stub *.nocache.js) > proxy rewrites per URL (we have multiple *.war deployed thus different > contextPaths but all are accessed from the GWT app) > Again, the reverse proxy doesn't rewrite paths, so everything should Just Work™. What would "not work" would be running several modules each corresponding to a different "context", as -modulePathPrefix can only match one of them; you'd have to run 2 devservers, one for each module, with the appropriate -modulePathPrefix, and one proxying to the other which would proxy to the "real" server. E.g. if you have a GWT app at http://example.com/context1/app1/app1.nocache.js and another at http://example.com/context2/app2/app2.nocache.js, you cannot use a single devserver for both modules; you'd have to use 2 devservers: devserver -proxyTo http://example.com -port 8889 -codeServerPort 9877 -modulePathPrefix context1 com.example.app1.App1 devserver -proxyTo http://localhost:8889 -modulePathPrefix context2 com.example.app2.App2 This is a bit heavyweight, but only needed when you want to work on *both* modules at the same time (BTW, the same is true with "CodeServer with -launcherDir", as you'd need 2 different -launcherDir values, so 2 CodeServer instances) > and finally the ability to add custom headers (mostly caching, but > x-forwarded-for / x-real-ip should also be there). > The Jetty (Async)ProxyServlet already adds X-Forwarded-* headers: http://archive.eclipse.org/jetty/9.2.14.v20151106/xref/org/eclipse/jetty/proxy/ProxyServlet.html#79 http://archive.eclipse.org/jetty/9.2.14.v20151106/xref/org/eclipse/jetty/proxy/AbstractProxyServlet.html#495 What kind of caching-related headers would you want? and why? For anything else, providing hooks that you can override in a custom subclass would likely be the way I'd do it (note that it's currently only a single <500 lines file, so forking is also an option; it obviously wouldn't be the case if the devserver were built into GWT proper) > Also GWT-RPC and GWT public resources should work as lot of people depend > on it. I actually did a contribution to provide gwt.codeserver.host but it > was abandoned in favor of writing GWT-RPC policy files to the -launcherDir > on each compile. That way if -launcherDir points to an exploded war a local > Jetty will just have them or you need to build the war and redeploy to a > remote server (or maybe use some network share). See > https://gwt-review.googlesource.com/#/c/9504/ for some discussion. > Hey, this is a currently just a prototype coded over the week-end ;-) I'd personally prefer not writing anything to the webapp, but as acknowledged in the OP we could have a -launcherDir option for serialization policies and possibly public resources (but then why not just use CodeServer with -launcherDir directly? one difference could be that devserver would never overwrite a file for example…) > Next there are people embedding the module.nocache.js file directly into > their host page (like me ;-) basically our host page is a servlet) and that > should work also during development. > I can't think of any other way to make it work (I did that too in one app) than having a way to switch from inlined *.nocache.js to external *.nocache.js on your server. There's absolutely no risk shipping that in production (it's only a network optimisation to avoid one HTTP request) so it looks like an acceptable compromise to me. …or you could just continue using CodeServer with -launcherDir. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/3280dc7f-148c-41c7-b2d8-6d831a08258a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
