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.

[mkurz]

Great!

[tyoshino]

Could someone with edit permission correct EvenSource -> EventSource in the title?

I think this is easy to implement on Chromium and wouldn't introduce so much complexity. Wanna hear other vendors' interest.

[ricea]

I work on the team that maintains EventSource for Chrome. EventSource is not being actively developed. We feel resources are better spent in filling the gaps in the more generally-useful facilities provided by fetch().

To give some idea of scale, fetch() body streaming is already used on ten times as many pages as EventSource in Chrome.

I acknowledge that the resumption facilities provided by EventSource are very convenient. However, you can already achieve the same things, with more control, in browsers that support fetch() streaming. I expect that every everfresh browser will support fetch() streaming before any browser supports setting headers for EventSource.

To be clear, I don't oppose improvements to EventSource. @danielwegener's arguments in #2177 (comment) are very persuasive. However, my team cannot justify spending any resources on it.

In summary: possible? yes. Likely to happen? no.

[essen]

I'll +1 on wanting to set the Last-Event-ID header in the initial request. The query string can be used as a pretty simple workaround but it's unfortunate to not be able to use an existing mechanism for the initial request.

I was looking into using fetch to consume the event-stream but it seems like I would have to reimplement the parsing and automatic reconnects which is a lot more work than I'm willing to go for.

[webmutation]

So if I understand correctly what is being said here it that SSE and WS are old technologies that should no longer be supported and authorization is not important to use it from a browser, even though every other client library does support Authorization headers... And while there is no real cross browser support for fetch or any protocol that would enable developers to use like WS or SSE, the only option is to send what would normally go thru a header as a query string.

@ricea would it really take more than a 2 week sprint to add this to chrome? Honestly?!

[LarsKemmann]

Exactly. I love the promise (pun intended) of fetch and streams, but doing right by the existing standards adds customer value now for a set of use cases that are becoming increasingly important while the implementers' roadmaps can continue to (slowly) converge on stream-composable fetch-based solutions.

[julienmachon]

2 years later, not a single browser has full support for fetch() streaming and we still can't set headers on EventSource 🤷‍♂️

[chicoxyzzy]

@julienmachon actually fetch streaming is supported in these browsers:

• Chrome 43+
• Edge 16+
• Safari 10+
• Opera 29+
• Firefox 65+.

It's still would be great to use headers in SSE though.

[tomuench]

Well, one year later @ultimaweapon.

I stumble over the same problem with OIDC. It would be a simple solution, if developers could set the header by themselves.

I found a possible workaround on stackoverflow: https://stackoverflow.com/questions/28176933/http-authorization-header-in-eventsource-server-sent-events

Maybe, WebTransport will be an appropriate candidate to build our use case. See https://w3c.github.io/webtransport

[rodorgas]

I'd like to share this polyfill that uses fetch streaming instead of XHR polling: https://github.com/Azure/fetch-event-source

We can easily set headers with this polyfill.

[hperrin]

Thank you @rodorgas for the solution.

It seems to me like this should be considered a known security vulnerability, since it forces developers to put auth tokens in the URL and URLs (even in HTTPS) are vulnerable. Even without an attack like that, URLs are often stored in log files, meaning auth tokens would be stored there too.

I think the solution here is to either add a custom header feature or just fully deprecate and eventually remove EventSource altogether. From a security standpoint, leaving it unchanged seems like a worse approach.

(Feel free to correct me if I'm misunderstanding anything here.)

[ericlaw1979]

it forces developers to put auth tokens in the URL and [URLs (even in HTTPS) are vulnerable]
(https://www.securityweek.com/hackers-can-intercept-https-urls-proxy-attacks/).

While I'm inclined to agree that putting auth tokens in URLs is distasteful on several levels, I'm compelled to note that that particular issue was patched[1] a month before the article was even written seven years ago.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=593759#c72

[stephen-dirtcreative]

The seemingly prevailing attitude that "this new API can do all these things if you take time to implement them, so these older APIs we created (to do 99% of the implementation) can go pound sand" is disheartening, and does nothing to promote trust or interest in using any API new or old. I could implement on this new API, but what's that down the road? The next shiny thing is just over the horizon? It may take 5+ years to be usable, and have a totally different interface, but we're all going to mark the current API legacy and divert all resources to the new stuff? Does the WHATWG need to start an LTS requirement for their API proposals so at least we have some idea how to gauge the utility of adopting an API if it's just going to be staleware in x months / years?

If Fetch is the way, can't the EventSource API be rebased onto Fetch, making it continue to be useful and relevant? Just a thought.

[atambi802]

Hello everyone! Just my 2 cents for this, I have an api, that is an SSE. It just spits data over local network and I just want people who have my bearer token to use it only, or else it is just open to anyone. I understand it isn't the most important thing, but adding some support of headers to the object would be so much better then making a websocket, and having to deal with the whole workflow with that.

[lukas-reining]

Hey, I also really like the server sent events protocol.
Using the fetch streaming API works, but then parsing is always up to the application writer.
This is why I created the following implementation, which is compliant with the spec and can be used where a native event source is expected. It can be used in the Browser, but also in Node, as long as fetch is available.

https://www.npmjs.com/package/extended-eventsource

[jschoch]

Another reason to add setting headers support is that it seems that for CORS-RFC1918 private network access you need to send " Access-Control-Allow-Private-Network: true" but this does not seem to happen when using event source in firefox or chrome, and so some thing seems to know enough about CORS-RFC1918 to kill the request, the eventsource doesn't know to send the correct header.

[ThiefMaster]

Yes, maybe fetch() is more powerful. But even the polyfill from Microsoft/Azure that supposedly implements SSE using fetch lacks even some of the more basic - yet useful - features, such as custom event types on the EventSource.

By not supporting headers you are basically making a useful and easy-to-use tool (it doesn't even require any external dependencies!) basically useless for anything that's not completely public (or using http basic auth for the whole site)...

[ricea]

Another reason to add setting headers support is that it seems that for CORS-RFC1918 private network access you need to send " Access-Control-Allow-Private-Network: true" but this does not seem to happen when using event source in firefox or chrome, and so some thing seems to know enough about CORS-RFC1918 to kill the request, the eventsource doesn't know to send the correct header.

JavaScript shouldn't be required to send the Access-Control-Request-Private-Network: true header, the browser should do that automatically. If it doesn't work then please file issues against the relevant browsers.

[annevk]

This is wildly off-topic for this forum. Please continue this discussion elsewhere.

[ezekielokoduwa]

@annevk Please, I just want to know now, is SSE still supported? because considering over the years, alot of people I know have preferred it over websocket for simple, straightforward usage, if you ask me, I'd say it is the 'fetch' for websocket, the 'guy' fetch thinks it is to XHR. That said, I tried using fetch to connect to a simple SSE server on a React native application, guess what? Your guess is as good as mine, it sucked, body kept returning undefined, and as such I couldn't even get the Readable stream via getReader. I had to use a different library, which apparently uses XMLHttpRequest under the hood, once again, not fetch. Seeing that this consistent habit of the working body, attempting to obsolete or make legacy of older tech, in favour of something 'new', is kinda appalling and saddening. The thing about APIs is that the implementation, under the hood can change, and new things added, leaving room for same access and usage.

But regardless we appreciate you all effort, but we, because I know I am not the only with such concerns or worries, as this thread has shown, we feel that the metrics been used to determine or make such decision is rather low or enclosed to what the working body thinks.

[annevk]

It's maintained, but nobody is actively working on new functionality. I suspect a couple dedicated people could probably get this change through, but it would require quite a bit of work:

1. WPT tests.
2. PR against the standard.
3. One or two implementations in browser engines.

[ezekielokoduwa]

Oh I see, Glad to hear it is still maintained and not totally gone. With the current feature it gives, I think that's pretty much fine with most of us.

[sagarpanchal]

It's maintained, but nobody is actively working on new functionality. I suspect a couple dedicated people could probably get this change through, but it would require quite a bit of work:

1. WPT tests.
2. PR against the standard.
3. One or two implementations in browser engines.

@annevk What are WPT tests?

EDIT: Got it. web-platform-tests.