- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 23 Jun 2011 13:44:28 -0700
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