2

Assume I have a gwt app on a large website which sets a lot of cookies, and that I'm not in control of which cookies get set. Assume further that my gwt app makes a number of REST calls to a lightweight API within the same domain (as indeed one must do) using RequestBuilder.

RequestBuilder reasonably enough makes an HTTP request to the server, and sends all the cookies it has received. The problem with this is that the cookies themselves sometimes take over 90% of the request size.

Yes, it would be nice if the web site did not set so many cookies, but assume this is unfixable. No, deleting the cookies from the browser is not an option (it's fine if they are totally inaccessible to / hidden from the gwt application, for instance if I could somehow persuade the gwt app to use a separate empty cookie jar).

How do I persuade RequestBuilder not to send any cookies?

Note solving this for XmlHttpRequest and wrapping it up in GWT code would be fine.

Things I found that might be useful (in general for JS and not for GWT, but GWT ultimately uses XmlHttpRequest):

  • Cookie Monster: An observer that steals the cookies from XmlHttpRequest before the request is sent. I think this might be Firefox specific, and it seems a bit like hard work.
  • yourXMLHttpReq.channel.loadFlags |= Ci.nsIRequest.LOAD_ANONYMOUS;: this would be pretty much perfect, save it requires surgery to get it into GWT and I think its Firefox specific.
  • This question, which handles Chrome extensions, the answer to which is to either remove and readd all the cookies (does not work for a long-running app), or use an incognito window (I want this to only affect the REST API call).
Community
  • 1
  • 1
abligh
  • 24,573
  • 4
  • 47
  • 84
  • I assume that Web Storage (http://www.w3schools.com/html/html5_webstorage.asp) is not an option for you. But I want to mention it because it is another approach to handle the problem. Storage objects are not sent to the server and vice versa with every request. – Charmin Feb 07 '15 at 16:04
  • @Charmin sadly not. The typical situation is that the app is on `app.foo.com`, and there is a `.foo.com` subdomain cookie-fest. – abligh Feb 07 '15 at 17:40

1 Answers1

2

RequestBuilder delegates to Javascript's XMLHttpRequest, which will always send cookies. You have two options.

  1. Use a different subdomain for your REST endpoints that cookies haven't been set for
  2. Temporarily remove all cookies during the request, and restore them afterwards
Bjartr
  • 492
  • 3
  • 18
  • Neither of those are options, sadly. First, I can't choose the subdomain (and in fact the issue is partly wildcard cookies being set for a higher domain). Secondly, the app is long running, so there is no obvious time to add them back. I'll add a little more information on where I got to with XmlHttpRequest. – abligh Feb 07 '15 at 09:57
  • Can't you add them back as soon as you've made the request? That's after the request is sent and is waiting for the response, so adding the cookies back then should be fine. – Bjartr Feb 09 '15 at 18:27
  • The app makes requests on a constant basis and in the background (hence the desire to optimise the communication). If they use another site within the same domain during the period and I've removed the cookie they will be signed out; if the other site changes the cookie but I restore the wrong one, other problems may ensue. As the browser is not single threaded, there is a race condition issue here. (I `+1`'d you a while ago btw as for many people this would be the solution) – abligh Feb 09 '15 at 19:17
  • (thanks) Could you setup a second, entirely-different, domain with CORS configured for the page origin, which on the server-side still routes internally to the same endpoint? – Bjartr Feb 09 '15 at 21:39
  • @Bjatr sadly the issue occurs when it is required to deploy the app as a subdomain of the domain with the wildcard. If I could use a different domain, I wouldn't need CORS (i.e. it's not the app container which is setting the cookies, but a marketing web site and/or separate SSO). – abligh Feb 09 '15 at 21:47