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 [email protected]. 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.
