GWT with XS. No POST, Just OPTIONS. Load cancelled - gwt

Question

I have a problem with a GWT Application which is rather simple but using the Cross-Site-Scripting mechanism of gwt in conjunction with the GWT-RPC (Async-Interface).
The Problem is, that the Browser is sending only the OPTIONS command to the RPC-Backend but not POST. Therefore the data never reach the server. This is the capture of the client-server-communication:
From the GWT-Client
OPTIONS /contact/contact/dispatchService HTTP/1.1
Host: svr3.dmz.mycompany.com:8380
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://www.mycompany.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31
Access-Control-Request-Headers: x-gwt-module-base, x-gwt-permutation, origin, content-type
Accept: */*
Referer: http://www.mycompany.com/contact.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
From the Server
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Allow: POST, TRACE, OPTIONS
Content-Length: 0
Date: Tue, 23 Apr 2013 07:13:06 GMT
But no data are beeing sent via POST.
In my module.gwt.xml I have the following line for using the xs-Linker:
<inherits name="com.google.gwt.core.Core" />
<add-linker name="xs" />
I have also tried xsiframe unfortunately with the same result.
When I directly invoke GWT-Application from the same server without cross-site-scripting everything works fine:
POST /contact/contact/dispatchService HTTP/1.1
Host: svr3.dmz.mycompany.com:8380
Connection: keep-alive
Content-Length: 273
X-GWT-Module-Base: http://svr3.dmz.mycompany.com:8380/contact/contact/
X-GWT-Permutation: 5BE2BF501B916E292DCA5282B8B896AE
Origin: http://svr3.dmz.mycompany.com:8380
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31
Content-Type: text/x-gwt-rpc; charset=UTF-8
Accept: */*
Referer: http://svr3.dmz.mycompany.com:8380/contact/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: __utma=179080955.1318578617.1360141977.1366109245.1366612633.29; __utmc=179080955; __utmz=179080955.1366104741.27.5.utmcsr=www.mycompany.com|utmccn=(referral)|utmcmd=referral|utmcct=/index.html
From the Server
7|0|9|http://svr3.dmz.mycompany.com:8380/contact/contact/|C4C9C36F0F0B498822C3C822496B3301|com.mycompany.contact.client.DispatchService|dispatch|com.mycompany.contact.client.DispatchService$Message/2078545930||lastname#mycompany.com|Direct via
svr3.|givenname|1|2|3|4|1|5|5|6|7|8|9|6|HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Disposition: attachment
Content-Type: application/json;charset=utf-8
Content-Length: 12
Date: Tue, 23 Apr 2013 07:15:44 GMT
//OK[[],0,7]
The Webapplication is running on a Tomcat6 behind an Apache2 connected via mod_jk.
Any idea how I can solve this issue?

Answer 1

This is known as a preflight request and is made by the browser when you do a cross-origin request (with a few exceptions for legacy reasons) to first check with the server whether the webapp is allowed to POST.
You have to handle the OPTIONS request on the server-side and respond with the appropriate Access-Control-Allow-Origin header (and possibly Access-Control-Max-Age, Access-Control-Allow-Headers, etc.)
See http://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0
Note that this will (obviously) only work in browsers that support CORS, which rules out a lot of people (IE only supports CORS starting with IE10, unfortunately not yet mainstream): http://caniuse.com/cors
See also https://developers.google.com/web-toolkit/doc/latest/FAQ_Server#SOP,_GWT,_and_XMLHTTPRequest_Calls
Using the xs linker (BTW, you should prefer the xsiframe linker nowadays, the doc is a little bit out-of-date) only fixes the loading of the script, it doesn't cover the requests to a server. You can use a proxy (servlet, script, server configuration, whatever) on the same origin as the HTML host page that routes the requests to the server where the RPC services are actually deployed; see https://developers.google.com/web-toolkit/doc/latest/DevGuideServerCommunication#DevGuideRPCDeployment

Answer 2

Based on the Information from Thomas Broyer I managed to resolve the issue by adding a CORS-Support-Filter:
First I added this to my pom.xml:
<dependency>
<groupId>com.thetransactioncompany</groupId>
<artifactId>cors-filter</artifactId>
<version>1.3.2</version>
</dependency>
Then added this to my web.xml:
<filter>
<!-- The CORS filter with parameters -->
<filter-name>CORS</filter-name>
<filter-class>com.thetransactioncompany.cors.CORSFilter</filter-class>
<!-- Note: All parameters are options, if ommitted CORS Filter
will fall back to the respective default values.
-->
<init-param>
<param-name>cors.allowGenericHttpRequests</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>cors.allowOrigin</param-name>
<param-value>*</param-value>
</init-param>
<init-param>
<param-name>cors.allowSubdomains</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>cors.supportedMethods</param-name>
<param-value>GET, HEAD, POST, OPTIONS</param-value>
</init-param>
<init-param>
<param-name>cors.supportedHeaders</param-name>
<param-value>Content-Type, X-Requested-With, x-gwt-module-base, x-gwt-permutation, origin</param-value>
</init-param>
<init-param>
<param-name>cors.exposedHeaders</param-name>
<param-value>X-Test-1, X-Test-2</param-value>
</init-param>
<init-param>
<param-name>cors.supportsCredentials</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>cors.maxAge</param-name>
<param-value>3600</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CORS</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Please see here for more information about the filter.
CAUTION: Further more I have tested this solution with IE 8 and unfortunately it is, as expected, NOT working with IE 8. I haven't tested it with more recent versions but since IE 8 is still in the wild I have to include the rpc-servlet into the same origin website via mod_jk.