Setting headers for EventSource

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?

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.

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

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.

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

stream.cancel()

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

@annevk

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

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.

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?

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

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

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

clients/web: use dedicated library to connect to SSE

I don't think complaining here is going to result in any outcome.

Request headers should be standardized. EventSouce is available in baseline but it is useless for most practical use-cases that require request headers.

Most of the devs who have to pass Auth headers end up using eventsource npm package https://www.npmjs.com/package/eventsource. This package has 4,613,039 weekly downloads, just because it allows custom headers, so we don't have to prompt users to enable cookies, if it's disabled.

This feature should either be deprecated and removed or extended to include request headers. Otherwise, it is just a bloat.

Because, backend devs will test their SSE endpoints on postman and opt to use SSE instead of websocket because SSE in postman allows request headers. Not including it in the spec is a very bad idea.

I came across this because I was looking for a solution to setting Authorization headers on this too. But it occurs to me that the most useful part of EventSource is actually in the parsing of the text/event-stream body, while fetch with streams handles the network side of things well.

I'm thinking rather than adding extra options to the EventSource constructor to handle Authorization, Last-Event-ID or whatever other options someone might want to use, the easiest and most flexible solution would be to consider leaving EventSource constructor as-is, but providing an alternative EventSource.fromStream(readableStream). Then we could open the connection using fetch, then call EventSource.fromStream(response.body).

That has the advantage of being easy to feature detect or polyfill by checking if fromStream exists, effectively separates the network handling of the feature from the event stream processing, and opens it up to getting any events from any other readable stream source.

Edit: EventSource.fromReadableStream() is probably a better name, and makes it clear it's not supporting NodeJS Stream API, which would be a relevant distinction for EventSource implementations made for node environments.

Can someone please point out how we can move forward here? I don't want to complain bluntly.

I'm just really interested in having Authorization headers into WebSocket and EventSource.

#2177 (comment) has the steps that need to be taken.

I had another look into how this might be addressed and the feasibility of speccing an EventSource.fromReadableStream() method that I proposed in #2177 (comment) and it seems workable, but there's a few issues that would need to be decided.

What should eventSource.url return when it's an instance created from a ReadableStream? Could be either an empty string or something like about:stream.
eventSource.withCredentials would just return false.
The reconnection time and last event ID are currently handled internally, but they would need to be exposed for applications to use them in their own reconnection logic, most likely via new reconnectionTime and lastEventId properties. It's not clear what eventSource.reconnectionTime would return prior to the server setting a value with the retry field. The current spec defines the default reconnection time as implementation defined. It could either return null, expose the implementation defined value, or otherwise the spec could define a set default value if there was consensus among implementers about what it should be.
A TypeError would have to be thrown if the ReadableStream was locked.
readyState would have to start OPEN. The CONNECTING state doesn't make sense when EventSource doesn't control the connection.
There's no reconnection behaviour. Once the stream signals done, then it's an error and it transitions to CLOSED. Applications could use a TransformStream, create EventSource.fromReadableStream(ts.readable) and pipe fetch response bodies to it using response.body.pipeTo(ts.writable, { preventClose: true }) to keep the stream open and handle reconnection independently.

2 of the 3 steps to get this pushed through are drafted.

WPT tests. --> Add WPT tests for EventSource.fromReadableStream() web-platform-tests/wpt#58550
PR against the standard. --> Add EventSource.fromReadableStream() #12272
One or two implementations in browser engines. --> ⌛

fix: replace abandoned SSE dependency with a maintained one

Harden sync correctness, account provisioning, and API safety (#987)

Navigation Menu

Repository navigation

Setting headers for EventSource #2177

64 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Setting headers for EventSource #2177

Description

Activity

annevk commented on Dec 15, 2016

chicoxyzzy commented on Dec 15, 2016

annevk commented on Dec 15, 2016

chicoxyzzy commented on Dec 15, 2016

domenic commented on Dec 15, 2016

annevk commented on Dec 16, 2016

danielwegener commented on Feb 8, 2017

annevk commented on Feb 8, 2017

LarsKemmann commented on Apr 11, 2017

kmayer commented on Jul 10, 2017

annevk commented on Jul 11, 2017

64 remaining items

DMurashko commented on Apr 14, 2025

sagarpanchal commented on Apr 19, 2025

ezekielokoduwa commented on Apr 19, 2025

lachlanhunt commented on Jun 19, 2025

danielo515 commented on Jul 29, 2025

Kludex commented on Aug 4, 2025

annevk commented on Aug 4, 2025

Yaropolki4 commented on Oct 23, 2025

lachlanhunt commented on Mar 16, 2026

lachlanhunt commented on Mar 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions