SSE with Chrome on iPad

Please! Tell me that it is supposed to work…
We are using an Angular SPA web app on Chrome on desktop and mobile.
Everything is ok on the desktop but ServiceStack SSE is not working on the iPad (iOS 15+, Chrome 9+).

Is there anything special I have to do to make it work?

This style of posting which doesn’t include any details of what’s not working or what errors you’re seeing isn’t useful. Can you please provide full context and details about errors e.g. full Exception StackTraces when reporting issues.

Sorry for the lack of details but I’m having a really hard time to debug Chrome on my iPad…
Since I also have the problem with Safari, I can troubleshoot with the Web Inspector but I don’t get much.

At first, I thought it wasn’t working at all. But suddenly, (I think after I had restarted the API and/or the WebApp on IIS), it connected and was working fine for a long time.
But the next day, it wasn’t.

I dot not get any error when I start the client. It takes a bit of time and I end up in the onException function with the error {“isTrusted”:true}. What is strange is that it seems that the OnSubscribe is getting called on my API with a sub id, but the client never gets connected, onConnect never triggers and the hasConnected() always returns false.

When it works, the Network tab gives me this on event-stream call (which is weirdly spinning all the time)

URL: https://…/api/event-stream?channels=main&t=1646169295242
Status: 200
Source: Network

Accept: text/event-stream
Cache-Control: no-cache
Origin: https://…
Referer: https://…/
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15
Pragma: no-cache

Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS
Content-Type: text/event-stream
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://…
Date: Tue, 01 Mar 2022 21:14:55 GMT
Access-Control-Allow-Headers: Content-Type,Allow,Authorization,X-Args,Access-Control-Allow-Headers,Access-Control-Allow-Origin,X-Requested-With,Cache-Control,Last-Event-ID
Cache-Control: no-cache
Vary: Accept
Server: Microsoft-IIS/10.0
x-aspnet-version: 4.0.30319

Query String Parameters
channels: main
t: 1646169295242

I do not get any errors in the backend API beside those very very very annoying Subscription xyz does not exist which I do not know how to get rid of…

Could it be something with how our Angular 12/ Ionic app is built? Would work ok with desktop but not with mobile in regards to SSE?

Thanks for your help.

This is expected since SSE as a technology "long poll"s with the server to receive information back from the server as a stream of events. These requests are still standard HTTP requests but instead of ending the request and getting the response as quickly as possible, it keeps the connection open waiting for event messages to be pushed from the server.

Please post the errors you are seeing from your Safari even if you don’t think they provide much useful information, it might provide additional context to your issue to help find the root cause.

It is also worth noting, if you are using some kind of reverse proxy between the client and server, this can cause network issues, is the iPad on a different network? I’ve seen these kinds of issues in corporate shared networks where their internet access runs through security proxies setup in the corporate environment that can interfere with SSE sending information back to the client. See this thread as an example of troubleshooting with a reverse proxy in the mix.

Without error information, we can only guess. Network information about the failed requests will likely provide a lot more context to help with trying to identify the root cause. Between days, did the browser remain open? Was the computer put to sleep between working and not working? Did a reload of the page fix it? Are you seeing any failed heartbeat requests?

You would have to provide an example of how your clients are connecting, and related errors you are seeing to rule it out, but generally I wouldn’t think so.

At last! Problem is solved. We added the possibility to turn the app as a PWA at the start of the project but never really pursue it. The problem is with the ServiceWorker. As soon as I have removed everything regarding PWA and recompiled, ServiceWorker not in the picture anymore, everything works just fine!
I am sure there is a way to use it and fine tune but for us now, no need.

That is why I did not have any errors to show you guys :slight_smile:
Thanks again for your prompt answers.