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?

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

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

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.

in my testing neither chrome or firefox sends the preflight request when using eventsource. When using https://github.com/Yaffle/EventSource only firefox is actually sending OPTIONS here's the issue i created for it https://github.com/Yaffle/EventSource/issues/226

[ericlaw1979]

I'm not sure what folks are trying, but I verified that Chrome 120 Stable and Chrome 122 Canary both send preflights for EventSource and both contain the Access-Control-Request-Private-Network header when required. Test Page

[jschoch]

both contain the Access-Control-Request-Private-Network header w

doesn't work for http using chrome http://espels.s3.us-west-2.amazonaws.com/eventsource_test/index.html

works fine on local network.

firefox seems to work, where do I log this issue for chrome?

[jschoch]

chrome works when disabling chrome://flags "Block insecure private network requests." but very oddly it doesn't issue the preflight check.

also, just to note that non secure ws:// seems completely unaffected by these flags.

[jschoch]

the lack of preflights with block insecure private network request off seems to be related to this:

https://bugs.chromium.org/p/chromium/issues/detail?id=1351185&q=Block%20insecure%20private%20network%20requests.&can=2

and also this: https://github.com/WICG/private-network-access/issues/23

seems like there is no win here for compute constrained stuff like commodity esp32 devices on your home network other than to have your users run a webserver or open up potential vulnerabilities by using flags like Disable: "Block insecure private network requests."

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

[bagatelli]

It's disheartening that such a brilliant feature like SSE implementation is simply not feasible to use because of the client's inability to set headers. It's been 8 years since the start of this topic and I'd think by this point, more than enough time has passed to debunk the "fetch" argument. Maybe interest would increase significantly if EventSource could actually be usable in real world scenarios. I do understand the reasoning behind abandoning "legacy" api's, as long as the new one is just as good and way more promising in solving problems. Which, 8 years laters, is definitely not the case.

[Gabilabrebi]

Soon 8 years later and this is still needed here.

Websocket or Fetch didn't replace EventSource at all. They co-exist, for different use cases and different app sizes.

[RIGHTHOOD]

ดาวน์โหลด Outlook for iOShttps://aka.ms/o0ukef

---

จาก: Gabilabrebi @.> ส่ง: Sunday, August 25, 2024 5:22:36 PM ถึง: whatwg/html @.> สำเนาถึง: Subscribed @.***> ชื่อเรื่อง: Re: [whatwg/html] Setting headers for EventSource (#2177)

Soon 8 years later and this is still needed here.

Websocket or Fetch didn't replace EventSource at all. They co-exist, for different use cases and different app sizes.

— Reply to this email directly, view it on GitHubhttps://github.com/whatwg/html/issues/2177#issuecomment-2308766955, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AMXKCYBDAMIWO5U3JCTMTRTZTGV6ZAVCNFSM4CZT77AKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZQHA3TMNRZGU2Q. You are receiving this because you are subscribed to this thread.Message ID: @.***>