I also had posted this issue here, but it was closed, but its clear other people have the same issue as they upvoted it as well: https://discussions.apple.com/thread/256112607?answerId=261517771022&sortBy=rank#261517771022

According to https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.7 6.5.7. 408 Request Timeout The 408 (Request Timeout) status code indicates that the server did not receive a complete request message within the time that it was prepared to wait. A server SHOULD send the "close" connection option (Section 6.1 of [RFC7230]) in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If the client has an outstanding request in transit, the client MAY repeat that request on a new connection. The client "MAY" repeat the request (I believe it does not have to be idempotent actually)! Because when safari tried to reuse a connection that determined to be closed during transit (in the server) but the client(safari) doesn't know yet (delay of microseconds) the transmission of data fails (socket is not open afterall the connection was closed), and so the request was not initiated or completed, due to keep alive timeout, which would be a error 408 Request Timeout. Safari could fix this by avoiding reusing connections near microseconds of time, as provided by the directive Keep-Alive timeout=1, or doing 1 single retry of the request event for POST or Preflight ones that affect POST Also I was searching in Chrome source code why this works fine, and how they solved it (apparently before 2014 chrome had that issue aswell and then fixed it) The code changes: https://codereview.chromium.org/303443011/patch/20001/30002 and the discussion of the change here: https://issues.chromium.org/issues/41110072

Also about the argument of the idempotency... No side effects can occur if connection is reset before body transmission. Other browsers open a new connection or retry in this case. I think Safari, should either open a new connection when close timeout is imminent (reading the timeout directive of Keep Alive), or retry the POST when no bytes were transmitted, which is the case because the connection is closed, nothing was transmitted, so this is not creating side effects like "double POSTing" thus can be considered idempotent safe, and can be retried. Spec 9110 9.2.2-6: "For example, a client might automatically retry a POST request if the underlying transport connection closed before any part of a response is received, particularly if an idle persistent connection was used." (https://datatracker.ietf.org/doc/html/rfc9110#section-9.2.2-6) Also related to https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.7 And the truth is that Safari <18 works fine... So what changed in safari from 17 to 18?

We use short Keep-Alive to limit idle connections to a few seconds for quick API bursts, then close them to avoid wasting server resources. About idempotent request, I'm aware of the specification, although let me tell you that GETs are being retried and the issue also occurs, with the "connection is lost" error when the GET includes Content-Type: application/json, which turns the request into a CORS “non-simple” request with a preflight and safari reusing closed connection for the preflight, it fails and the GET request fails entirely. POST should also retry if the connection closed before sending, like other browsers do and Safari used to. Because no backend POST change occurs since the request never reached the server, so retrying is safe... even if its not in the specification... This is what google does, and all browsers do actually, and safari did previously. This Safari 18+ behaviour is a regression in connection reuse also caused by failed preflights and POST (breaking apps performing POST actions as well) Other browsers works fine. I'm aware of many others users/Devs reporting the same issue, so this change is widely breaking expected web behavior. When Keep Alive is turned off this issue does not occurs. So if this was an issue introduced by safari 18+, only happens on Safari browsers, then for me this is a regression of expected behaviour and should be fixed...

I have a similiar network issue but it is with real devices and simulator, after safari 18+ In my case it related to connection lost due to keep alive and the reuse of a dead connections. See: https://developer.apple.com/forums/thread/796906?login=true

Anyone? Looks like no one cares, is there a more specific place where I can discuss this issue? I already open the feedback and no reply whatsoever

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... :(