11835 2011-01-21 19:07:56 +0000 EventSource must support cross-domain requests (ala CORS) 2011-06-18 08:27:44 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Server-Sent Events (editor: Ian Hickson) unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#top P2 major --- 1 contributor ian annevk art.barstow glenn ian jackalmage louisremi mike Ms2ger public-webapps robert public-webapps-bugzilla oldest_to_newest 44576 0 contributor 2011-01-21 19:07:56 +0000 Specification: http://dev.w3.org/html5/eventsource/ Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#top Comment: Please do *not* require a same-origin restriction in user agents (as currently specified under "Security Considerations")! This cross-origin data leakage security issues have already been addressed by the CORS specification (http://www.w3.org/TR/cors/). EventSource should simply adopt the policies outlined there. I consider this a critical flaw, as cross-domain requests are essential to working around useragent connection limits. Unless this is addressed, developers will simply ignore native useragent implementations and write their own, XHR+CORS-based, APIs (as they're already doing.) This spec will be nothing more than tepid inspiration for those 3rd-party solutions, and ignored otherwise. Posted from: 66.220.144.74 44577 1 robert 2011-01-21 19:14:00 +0000 Currently the EventSource spec imposes a same-origin restriction on user agents. This is simply not acceptable. EventSource requires a persistent connection, which conflicts with the per-domain connection limits imposed by user-agents. The one viable workaround for this issue is to issue persistent requests on a subdomain, which requires the ability to do cross-origin requests. I'm puzzled why EventSource wouldn't simply adopt the CORS spec for doing cross-domain requests? Frankly, that seems so obvious a solution that I feel I must be missing something.... am I? 44578 2 jackalmage 2011-01-21 19:14:41 +0000 (In reply to comment #0) > This cross-origin data leakage > security issues have already been addressed by the CORS specification > (http://www.w3.org/TR/cors/). EventSource should simply adopt the policies > outlined there. I don't understand how CORS lets us avoid a cross-origin restriction. CORS is designed to *lift* cross-origin restrictions. It can only operate if there's already a restriction in place for it to lift; it doesn't *create* any new restrictions. Thus, we either don't put any restriction, and are stuck with it always being fully open, or we put a cross-origin restriction in, and let CORS selectively relax it when necessary. 44579 3 robert 2011-01-21 23:17:57 +0000 (In reply to comment #2) > I don't understand how CORS lets us avoid a cross-origin restriction. CORS is > designed to *lift* cross-origin restrictions. It can only operate if there's > already a restriction in place for it to lift; it doesn't *create* any new > restrictions. Thus, we either don't put any restriction, and are stuck with it > always being fully open, or we put a cross-origin restriction in, and let CORS > selectively relax it when necessary. Under, "Security Considerations", the spec currently reads, "user agents are required to block all cross-origin loads." There is no provision made for using CORS as a way to lift this restriction. That's a problem. 44605 4 annevk 2011-01-22 11:25:14 +0000 EventSource will get CORS support in due course. CORS is still somewhat experimental at the moment so we are waiting a bit. 45657 5 ian 2011-02-16 08:22:36 +0000 Anne is correct in comment 4. 49583 6 louisremi 2011-06-14 16:28:09 +0000 We are talking about a specification here, not an implementation. It is a draft, not an experimentation. Let's allow CORS in the spec so that implementors can *experiment* with it and provide useful feedback about CORS and how it would play with EventSource. Waiting for a spec to get more stable before experimenting with it seems illogical to me. 49719 7 glenn 2011-06-16 18:30:34 +0000 I propose to resolve this issue by removing all requirements pertaining to cross-origin uses. As such, this specification defines a mechanism (SSE), but when it starts placing requirements on how this mechanism is used (e.g., in a user agent), it ventures into policy requirements. There is no technical aspect of such policy requirements for which the mechanism itself is technically dependent. Therefore, the policy requirements should be removed from this spec, while continuing to note the relevant security issue. Different uses of the SSE mechanism may wish to employ different policies as well as different techniques to enforce specific policies. As such, this specification should be written in a manner to accommodate all such uses, including a policy that ignores the security issue (because, e.g., other security mechanisms effectively prevent the problem at a higher level). If HTML5 wishes to normatively employ SSE *and* require CORS or equivalent protection, then the HTML5 specification should be the point at which such requirements are defined. G. 49828 8 Ms2ger 2011-06-18 08:27:44 +0000 http://html5.org/tools/web-apps-tracker?from=6254&to=6255