Hello, Yes I already have a feedback Id: FB19582986 Yes, the server has a short keep-alive timeout of 1s, as explained. It has always worked fine in other browsers (Chrome, Android, etc.) and even Safari versions before 18. Our business case relies on this short timeout to improve API response speed for quick user actions or specific endpoints, we don't want to keep connections alive longer than needed. Also, changing the timeout to 30s doesn’t fully solve the issue, it only postpones it. If a user action triggers a request just before the timeout, the connection may already be closed when it reaches the server, and the request will still fail. We’re aware of HTTP/2 and 3, but that’s not the topic here. This behavior worked before Safari 18 and continues to work on all other platforms. You can’t “break the internet” like this, I can’t be the only one affected. Thanks.

I just wanted to add that I’m encountering some strange network issues when running web SPA, on the iOS simulator for versions 18.4 and 18.5 , but not on 17.0! The network failures happen randomly and i can totally reproduce them after some tries. When inspecting via Safari’s Web Inspector on the simulator, the failing requests show the following error: “Failed to load resource: The network connection was lost.” In the network panel, these failed requests show completely empty values for status, protocol, connection ID, IP, and transferred size. They also fail very quickly and never even show up in the server logs, which makes them really hard to diagnose. Interestingly, this behavior seems to be specific to Safari on iOS and macOS. They work without any issues on Chrome or Android, no failures at all. I suspect this might be related to how newer iOS versions handle network connections, particularly keep-alive connections. It’s possible that Safari is attempting to reuse a connection that the server has already closed, and doesn’t know how to recover gracefully from that. Just to emphasize: • This happens in Safari 18.4 and 18.5. • Safari 17.0 runs the exact same app flawlessly. • I haven’t tested any versions between 17.0 and 18.4 yet. Not sure if related to this URLSession but the error is very similar...

I have the same issue! Adding a session Storage entry using for example postMessage to an iframe for a "domain.com" from "app.domain.com" will not work. This works in chrome like always did! So this is breaking some code... :(