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?

(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.

(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.

EventSource will get CORS support in due course. CORS is still somewhat experimental at the moment so we are waiting a bit.

Anne is correct in comment 4.

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.

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.

http://html5.org/tools/web-apps-tracker?from=6254&to=6255