Cachin Session Token in Page Cache

Hi,

In Services module is missing out on page caching, sending wrong header info, support was added for page caching for anonymous users. It appears this is also caching the session token obtained from /services/session/token, also causing Drupal to send ETag & last-Modified headers.

Is the session token something that ought to be cached in general? It might be too late here & I'm not wrapping my mind around it.

However, it appears this behavior does cause a problem in the following scenario I have encountered:

I have one back end using Services to serve resources over a REST endpoint. I have two front ends (AngularJS apps) at different subdomains accessing this back end. Because the session token is cached, it causes Drupal to send an ETag. This causes the browser to send the If-None-Match headers & get a 304 in response. Apparently then the browser on subsequent requests from the second front end (at a different subdomain from the first front end) tries to match the Access-Control-Allow-Origin CORS headers from the server with the domain of the first front end subdomain, causing XMLHttpRequest cannot load http://backend.example.com/services/session/token. The 'Access-Control-Allow-Origin' header has a value 'http://subdomain1.example.com' that is not equal to the supplied origin. Origin 'http://subdomain2.example.com' is therefore not allowed access. (in Chrome, comparable error in Firefox). It seems because of the ETag, caused by the page caching (see bootstrap.inc function drupal_serve_page_from_cache(stdClass $cache)), the browsers are caching the Origin value from the first request & attempting to send it with the token request to Services, causing the CORS mismatch. Disabling page caching of the tokens eliminates this problem.

In short, is caching the session token necessary or desirable, or an unintended consequence of the fix in the previous issue?