Question

On port 80 I have normal apache web server.

On port 8080 I have tomcat with client and server side stuff.

My goal is:

http://www.mydomain.com renders a static and SEO friendly index.html while javascript stuff is loading.

In the header of this index.html I load http://www.mydomain.com:8080/myapp/stuff.js

stuff.js is compiled with gwt and calls a RootLayoutPanel.get().add(nice_panel) which will remove static content and show dynamic widgets. It also calls servlets (server side code).

Problem: for security reasons, browsers wont let me load http://www.mydomain.com:8080/myapp/stuff.js because it is on a different port.

Wrong attempt: I tried to create a symlink from “normal” apache web server directory to the tomcat webapp containing stuff.js. I am now able to load stuff.js because its url is: http://www.mydomain.com/mysymlink_to_tomcat/stuff.js. But stuff.js is not able anymore to call servlets on server side again because of browsers security rules (“XMLHttpRequest cannot load … origin …is not allowed by Access-Control-Allow-Origin”).

I would like to avoid the “crazy” solution of redirect from index.html to tomcat with header(‘location: http://mydomain.com:8080/another_index_on_tomcat.html‘). This solution works but it has many drawbacks (SEO…)

What would be the best approach ?

Thanks.

Answer 1

You have basically two solutions:

• make it work with the 2 origins: use the xsiframe linker in GWT to allow the page on :80 to load the script from :8080 (for readers: it’s not about loading, it’s about what the script does).
  Add the following to your `gwt.xml:

  <add-linker name='xsiframe' />
  

  That unfortunately won’t solve your issue with GWT-RPC (o whatever you use to talk to the server). For that, there’s CORS.

• use a single origin: use Apache’s mod_proxy (or mod_jk) to proxy your Tomcat through your Apache. Nobody will ever use :8080, everything will go through :80. See Using Tomcat with Apache HTTPD and a proxy at https://developers.google.com/web-toolkit/doc/latest/DevGuideServerCommunication#DevGuideRPCDeployment

And of course there’s also the solution of ditching the HTTPD and serving everything with Tomcat (recent Java and Tomcat versions have fixed their slowness issues).