W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2011

[whatwg] Enhancement request: change EventSource to allow cross-domain access

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 23 Jun 2011 13:44:28 -0700
Message-ID: <BANLkTi=J71P1gTG24vBE5xTq0cjB5FSujg@mail.gmail.com>
On Sat, Jun 18, 2011 at 7:06 AM, ilya goberman <goberman at msn.com> wrote:
> We are a financial market data vendor streaming real-time market data.
> We currently have a cluster of servers servicing market data. These servers
> are hosted by our company and therefore have different domain from the
> client web pages domain.
> We try to have Comet connection to stream data from servers to clients (as
> opposed to long poll). The data _is_ personalized based on user subscription
> request. We generate "client id" we send with every comet request to
> identify clients.
> We currently use XHR, but it has limitation of growing response string and
> requiring periodic disconnects, so EventSource is just another delivery
> mechanism that does not require disconnects. So again 2 things:
> 1) EventSource is not really that different from XHR from our perspective,
> the only advantage is that it does not require periodic disconnects.
> (Actually now it does require disconnects because it incorrectly buffers
> response (fixed in the latest WebKit)).
> 2) XHR CORS changes should be backward compatible. We do not really want to
> find out that our servers stop working because a new browser is released.

Indeed, changing XHR CORS is not really an option at this point given
how widely it has been deployed. No-one is proposing to do that. And
EventSource is generally agreed to be similar enough to XHR that it
could share security model.

So with that in mind, I still don't understand how you are using XHR
and CORS today. On one hand you are saying that you are sending a
header like:

Access-Control-Allow-Origin: *

On the other hand you are saying that you are sending personalized
data. Is this data personalized based on the user's cookies? Or based
on something that you send in the URL which identifies which user's
data is requested?

The reason I'm asking is that the CORS specification specifically does
not allow the "Access-Control-Allow-Origin: *" header in requests that
use cookies. And I believe that all existing CORS implementations
follow that part of the specification. If you send that header the
browser should reject the response and the XHR should just give you an
error code.

Again, note that this is not a change to CORS, this is how CORS has
always been specified and implemented.

/ Jonas
Received on Thursday, 23 June 2011 13:44:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:06 UTC