Setting headers for EventSource

[chicoxyzzy]

Seems like there is no way to add Authorization header or any other headers for EventSource. Is there any reason it shouldn't be possible?

[annevk]

The main reason to not allow this is that this feature can somewhat easily be written on top of fetch(). I'm not sure we need put more effort into the "legacy" XMLHttpRequest, WebSocket, and EventSource networking APIs.

[chicoxyzzy]

Hmm... I have not seen any SSE alternatives based on Fetch yet. Do you know any implementations?

[annevk]

No, sorry. It's also still a little early since only Chrome supports https://streams.spec.whatwg.org/ for now. But you can build any kind of abstraction on top of that. You would also no longer be limited by the SSE format and such.

[chicoxyzzy]

How should we cancel a Fetch stream? Cancelable Promises proposal is withdrawn.

[domenic]

stream.cancel()

[annevk]

Closing this since I don't think we'll be able to find sufficient interest to extend this API.

[danielwegener]

@annevk What would indicate a sufficient interest?

SSE is IMO a really nice standard for implementing simple web-based queue-consumers with out of the box at least once consumption semantic and I think it has very real use-cases. But as stated above it obviously lacks the following capabilities:

• Provide authentication as HTTP-Header
• Provide an initial Last-Event-ID-Header that can be used to step into an already partially consumed stream (e.g. to resume from a certain position after a page reload).

There are also quite a lot active server-side implementations of SSE out there.

It's use-cases really come to shine with event-based/ reactive backends. Something that is, compared to REST, not necessarily the thing yet, but (given all the reactive/async/streaming movement going on in the backend world) seems to be relevant enough (probably needs references).

It would of course be possible to build something similar with fetch - but it would not follow any standard and assumptions like "hey this client library and that server library supports SSE - so we can probably wire them together" will no longer hold. And beside this spec there is no such thing as standard GET for event streams.

So, I'd second to keep the EventSource/SSE standard alive and move it forward to support custom headers.

[annevk]

I'm not sure, but over the past decade I've heard this request from three people or so, which is not really enough. Also, you can continue to use server-sent events and the server-side implementations thereof, you would just need to implement the client-side bits using fetch() if you want to transmit more headers.

[LarsKemmann]

Make it four. :) We recently chose SSE over Web Sockets for a reactive app because it's much simpler to program against and the built-in reliability is nice. Having to work around the lack of custom headers support by putting the authorization token in the query string is probably the one thing really missing from the standard. Why should we pause use of a perfectly good technology and wait until replacements come out?

[kmayer]

I have a working implementation, forked from Yaffle's polyfill.

Yaffle/EventSource@master...kmayer:kmayer-2

[annevk]

Given the (renewed) interest in this I'll reopen. We'll still need implementer interest.