Safari AJAX bug - Failed to load resource

2019-04-09 14:06发布

问题:

since today I have a pretty strange bug in an web app I'm working on. I haven't done anything to the code and from one day to another this bug appeared:

I execute AJAX requests (not with jquery but with normal js) to our local server running MAMP PRO. All works fine in chrome and firefox (testing on a mac). But in safari the request always throws an error: Failed to load resource: the network connection was lost

When I try to load the url of the request manually (not via AJAX) everything works fine. I also tested the request with a setTimeout and found something interesting:

When I do the request directly after page load (up to 60 millisecs) all works fine. After that the connection is lost sporadicly till 6000 milliseconds where everything works fine again! Pretty strange behaviour... I'm not working with any other setTimeouts so the problem can only be caused by safari.

Am I doing something wrong or is this just a very new safari bug?

回答1:

I have seen some mention elsewhere that Safari on Mac has problems with keep alive. Some people are posting the solution is to disable keep alive for safari on mac at the server.

BrowserMatch "Safari" nokeepalive



回答2:

In developing a large new feature for our web app, we ran into this problem as well. We use an XHR request from the JS client to get user favorites from the Tomcat server hosted on Amazon Linux. The initial connection works fine as expected. However, the second identical request fails with "Failed to load resource: the network connection was lost" in the client JS console. I suspect Safari recognizes the second request as a mistaken duplicate of the first.

The current workaround we are using for Tomcat is to effectively disable KeepAlive support. Unfortunately, this affects all connections, not just for Safari on desktop and/or mobile. This solution for Tomcat is to set a parameter on the Connector for HTTPS in ${CATALINA_HOME}/conf/server.xml...

maxKeepAliveRequests="1"

There might be other solutions to limit the damage to only Safari connections. If I discover them, I'll come back and update this post. The better band aid would be to cache results in our app and avoid the problem altogether.