https://stackoverflow.com/questions/75794431/safari-localstorage-login-from-sub-domain-com-to-domain-com

Hello, Any news about this issue? Feedback Id: FB19582986 Yes, server has a short keep-alive 1s timeout as explained. It always worked in other browsers (Chrome, Android, etc.) and even Safari versions before 18. Changing timeout to 30s doesn’t solve the issue, it only postpones it. If user triggers a request just before the timeout the connection may already be closed when reaches server, and the request will still fail. We’re aware of HTTP/2 and 3, but that’s not doable at moment Thanks.

Can you see the feedback Id I provided (FB19582986)? Thanks.

No one replies to the feedback... (https://feedbackassistant.apple.com/feedback/19582986) ? The problem is still on going...

Sorry any news about this issue, that is still an issue? Is this any bug from safari, can you confirm anything?

Other users with similar issues: https://github.com/supabase/supabase/issues/20982#issuecomment-2944288493

I replied bellow with more info, since text does not fit this comment response. We dont use body in GET I meant content type sorry.

So do you know why this issue only appears on new safari 18+ devices?

So apple just decides to break internet like that just because the use of a param is low... Well the param is not deprecated according to Keep alive Specs. Also, this case is not a timeout of 29s? in my case we use short keep alive timeouts for quick bursting actions cases (which is where this fails in our cases) . Issue still happens. But I know about many other cases like SupaBase servers and many others with the same problem of randomly connection closes causing "network error"

@Frameworks Engineer please let me know when the issue is resolved so we can test it. Currently, we had to completely disable Keep Alive for Apple devices to avoid the problem. However, Keep Alive and the timeout parameter should be considered when closing idle connections. Should heuristically determine when a connection is about to close and open a new one without the restrictions of idempotency, as these cases are safe to repeat since no requests actually reach the server