25984 2014-06-04 22:53:15 +0000 EventSource should support RequestInfo 2015-09-15 08:22:24 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#top P3 normal 2015 Q1 26533 1 contributor ian annevk ian mike naasir.ramji contributor oldest_to_newest 107300 0 contributor 2014-06-04 22:53:15 +0000 Specification: http://www.w3.org/TR/eventsource/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Referrer: Comment: Section 4: The EventSource interface does not permit to set request headers. This is a limitation for applications that may want to use custom headers to transfer small tokens of information between client and server. Posted from: 24.69.56.242 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36 107301 1 ian 2014-06-04 22:58:49 +0000 What's the use case? Can't you just put the information in the URL? 109978 2 ian 2014-08-06 00:21:39 +0000 This'll probably end up fixed by exposing 'fetch' objects or something. 119002 3 naasir.ramji 2015-03-28 08:33:11 +0000 Any update on this? I think one very legitimate use case for supporting custom headers with the EventSource API is when communicating with an SSE endpoint that handles authentication via OAuth2. OAuth2 seems to be the current de facto standard for securing an API. The recommended best practice for having clients specify their OAuth2 access tokens is via the Authorization header and NOT through query parameters in the URL (as URLs are often logged). See last bullet point here: https://tools.ietf.org/html/rfc6750#section-5.3 Would love to get more details on the 'fetch' objects proposal... Thanks! 123201 4 annevk 2015-09-15 08:22:24 +0000 You can basically do what EventSource does and much more with fetch() + streams. I don't think it makes sense to extend EventSource given that.