TCP preconnect requests causing intermittent failures with some websites

By design Issue #7553785

Details

Created
May 13, 2016
Privacy
This issue is public.
Found in
  • Microsoft Edge
  • Internet Explorer
Reports
Reported by 8 people

Sign in to watch or report this issue.

Steps to reproduce

Internet Explorer and Microsoft Edge open TCP preconnect connections for performance. If these connections are aborted by the server (when the server sends a TCP FIN), IE/Edge will ACK this but not send its own FIN, leaving the connection in a half-open state.

In our case, this bug manifests itself with HAProxy. When HAProxy is configured with a client timeout, it will send a FIN to Edge. Edge will ACK this but not send its own FIN. The next request that hits HAProxy will get a 408 “request timeout” immediately.

Eliminating (or dramatically increasing) HAProxy’s client timeout IS a workaround but not a satisfactory one; this would leave many stale connections open for any browser, not just Edge.

We cannot see these preconnect requests in the Network tab in the developer tools but we can see these preconnect packets when we use the Wireshark tool.

We are not the only people to find this issue (or something like it): http://comments.gmane.org/gmane.comp.web.haproxy/15263

This problem appears to have happened in Google Chrome as well, though they appear to have fixed it: http://blog.haproxy.com/2014/05/26/haproxy-and-http-errors-408-in-chrome/

Attachments

0 attachments

    Comments and activity

    • Hello, we seem to be experiencing a problem in Edge / IE11 with similar symptoms.

      To put it simply, we are using CORS to POST to a cloud file upload service. The browser will first do an OPTIONS request for the could destination URL and then a POST request to upload the file. This works 100% of the time in Chrome and Firefox.

      In Edge/IE11, every now and then, the OPTIONS request fails with a 408 error. There is no pattern, the error will happen any time. It can be as frequent as every other request (but never two consecutive requests), or we can go 50-60 requests without encountering the error again.

      We ran Wireshark and saw that when this error occurs on the OPTIONS request, there is a TCP-level problem with the request.

      If we run the IE11/Edge session through a proxy tool like Fiddler, the problem doesn’t seem to occur at all!

    • Microsoft Edge Team

      Changed Assigned To to “Rico M.”

      Changed Assigned To from “Rico M.” to “Venkat K.”

      Changed Assigned To to “Ivan P.”

      Changed Assigned To from “Ivan P.” to “Matthew C.”

      Changed Status

    • Issue shows as fixed but does not reference a patch. How is this fixed?

    • As the original poster of this issue, I can confirm that it is not resolved. We still are logging a significant number of 408 responses to Edge closed connections in our environment.

    • The ticket system does not seem to allow me to reopen this issue.

    • I’m encountering the exact same issue, when can a resolution be expected?

    • This is something I have seen as well and does not seem to be fixed.

    • Microsoft Edge Team

      Changed Assigned To to “Brad E.”

      Changed Status

    • In order to receive the fix you need to be running the anniversary update. Are you confident that you have applied the anniversary update before re-running your tests?

    • Microsoft Edge Team

      Changed Status to “By design”

    • The 408 responses are generated by the server. The browser fix was to handle properly 408 responses.

    You need to sign in to your Microsoft account to add a comment.

    Sign in