This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
What's the use case? Can't you just put the information in the URL?
This'll probably end up fixed by exposing 'fetch' objects or something.
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!
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.