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.

Reply via email to