bug: CapacitorHttp - No support for Server-Sent Events (EventSource API)

[torte]

trafficstars

Bug Report

Capacitor Version

@capacitor/cli: 4.7.0 @capacitor/core: 4.7.0 @capacitor/ios: 4.7.0 @capacitor/android: 4.7.0

Platform(s)

iOS and Android regardless of version

Current Behavior

When using the web's EventSource API for use with Server-Sent Events, the CapacitorHttp plugin won't be used and instead it falls back to the web's native implementation. This is caused CORS issues when intending to use device's native HTTP handling (hence the usage of CapacitorHttp).

Expected Behavior

As with fetch and XMLHttpRequest, EventSource should also be patched and work through device native events.

Additional Context

Likely related to other issues similar to this since the Content-Type is text/event-stream for Server-Sent events: https://github.com/ionic-team/capacitor/issues/6299 & https://github.com/ionic-team/capacitor/pull/6206 ?

[ghost]

I tried to use https://github.com/Azure/fetch-event-source to get a fetch() based approach for text/event-stream, but even that isn't good enough, since the patched fetch can't seem to stream data.

[youngerjo]

I'd like to kindly request the Ionic team to consider adding support for the text/event-stream response type. This would greatly benefit scenarios like integrating OpenAI's chat completion with streaming, which is currently not achievable using the Capacitor's HTTP module. Thank you for considering this!

[ghost]

@youngerjo the type is not enough. the entire http client needs to be restructured to support streaming data. I wonder if they should adopt OkHttp instead of trying to write it themselves

[youngerjo]

@jrobeson Thanks for pointing that out. For the time being, I might lean towards using the web fetch method for streaming responses. My main concern with that approach is the limitation of not being able to include an authorization header due to CORS restrictions. I genuinely hope the team considers restructuring the http client or integrating a more efficient solution like OkHttp in the future.

[torte]

Yeah, CORS has also been the main problem with our app just using native fetch. For just HTTP with simple content-types like application/json or text/html the current http plugin works fine, but everything else it does not. For now can not use SSE at all in the mobile app OR would need to make my app insecure essentially.

[nimo23]

In https://github.com/ionic-team/capacitor/issues/5145#issue-1027763992, nothing was said about SSE and it may be that it was simply forgotten at the time or there were other reasons why it was not included in capacitorHttp.

@thomasvidas, can you tell us whether SSE was even planned or whether it is even possible to include this?

Especially for mobile applications, SSE is a much more energy-saving alternative to "fetch with polling", for example. Btw, in contrast to the use of the "web's native implementation", capacitorHttp can even improve SSE communication by

• optionally bypassing a "push proxy" (https://stackoverflow.com/questions/46799463/server-sent-events-sse-connection-loss-on-mobile-phones) leaving SSE communication intact for the native application.
• use the native timer for SSE retry field (instead of the web timer)

[maelp]

Is there also a way to use streaming HTTP request? I can do it from my web-app using fetch with a keep-alive connection, but it doesn't work once compiled to Capacitor

[IsaSalemHame]

Any update?

[jaspart]

Any update?

[th1nkgr33n]

Any Update?

[klauss194]

such a pitty that capacitor team wont reply to all these requests. Guys I highly recommend if possible -> just move to a pwa. apple its not killing them anymore

[pizzaeater]

I'm missing support of SSE in the CapacitorHttp. Could we get any updates regarding this feature, please? Thank you.

[mdledoux]

What is the reason for even needing support in CapacitorHttp? I actually use Angular and use @angular/http (HttpClient) in all of my services - so I haven't really needed the Capacitor plugin, which only a couple years ago was still a community plugin.

I have an assignment to implement SSE in my Angular app, and my plan was to write a service that directly uses the EventSource API, but then I discovered that doesn't take headers. So I did some digging, and my plan is to use the EventSourcePlus module in my service (in order to add Auth headers to it). Is there something wrong with this, or is this more of an issue for other frameworks which don't have a built-in HTTP client? (though I would have assumed that React and Vue devs are just using Axios - same question I suppose: What is the reason for not using Axios (or even fetch) in an Ionic+Capacitor app?

[mdledoux]

I'll also out that since this issue was opened in May of 2023 (using Cap 4.7.0), Capacitor 5 came and went, and Capacitor 6 came out April 15, 2024, and Cap 6.1 came out June 11, 2024. I'd be curious if anyone has better luck with these in the latest version.

Update: Sadly, I see nothing about SSEs or EventSource in the CHANGELOG

[torte]

@mdledoux You are right, you can achieve the same with regular web http client libraries and the EventSource API, but with caveats. One main caveat for me was that (at least at that time when I opened the ticket) you had to apply an open CORS policy on your backend, because the web API's run from the Capacitor mobile app don't set a trustworthy origin header (localhost isn't trustworthy on a production environment). There seems to be an option to overwrite that, but that didn't work for me, so I ended up trying CapacitorHttp and ran into more fundamental issues there (hence the ticket).

Maybe the soluition is to be actually able to configure the Origin header instead of "falling" back to the native HTTP clients as CapacitorHttp does. That being said, setting an arbitary Origin header should also not be allowed in your config, because you would be able to hack other sites like this. So I guess the whole thing is a bit more complicated and there would be at least some validation process needed to achieve this (kind of how you validate your website with Android/iOS deep linking).