0

I have written a REST API and have noticed an issue which seems to affect Chrome and Safari when connecting through 4G, and when tethering the phone to a Mac and using Chrome there. When using Firefox on Mac tethered to the phone there is no problem.

Not tested on Windows yet.

When using Chrome on Android through 4G the issue is present.

Apache/PHP/Slim framework based back end. JQuery based front end making $.ajax() calls over HTTPS.

The POST request stays at the "Stalled" stage for a variable amount of time, before failing with net::ERR_TIMED_OUT

Chrome DevTools

When the request goes through successfully, the stalled time is usually around 2ms.

In chrome://net-internals/#events I see for the relevant request:

REQUEST_ALIVE --> net_error = -7 (ERR_TIMED_OUT)

As this is a client side stage in the process of making a request I wondered whether my client side code is to blame, and followed the advice here:

https://stackoverflow.com/a/27514611/6315532

I added cache:false and Cache-Control header with no-cache, no-store, must-revalidate amongst a few other things and this didn't seem to have any effect.

I also tried this: https://stackoverflow.com/a/367827/6315532

The issue goes away when using home WiFi, suggesting it's something to do with the 4G network, but as Chrome is sticking on a pre-network phase of making the request I'm mystified.

It works successfully about 1/3 of the time when on 4G, and seems to be reliable when on home WiFi.

Thanks in advance!

EDIT: I've found that if I alter the KeepAlive configuration in Apache this problem can be reduced.

If I fire off the requests before the KeepAlive timeout has elapsed it works fine. If KeepAlive finishes (no requests for a period), the first subsequent request will stall for up to several minutes then fail with ERR_TIMED_OUT, and further requests will then work successfully until the KeepAlive timeout is allowed to expires. Is there something I could be doing wrong to cause this?

I have adjusted KeepAliveTimeout to be a higher value and this makes the app less likely to encounter a problem, but if it's left alone for more than the timeout I know it's going to fail again, not to mention memory usage issues if the site gets busy.

Robin
  • 321
  • 1
  • 3
  • 10
  • 1
    I'm no expert in network connections but do you have a firewall/proxy that might be blocking the request on specific networks or for a specific application (i.e. : Chrome)? – Jérôme B Nov 21 '18 at 15:08
  • Not that I know of, and as it's working fine probably 1/3 of the time I don't think it's being blocked by a rule. From the docs it sounds like the "Stalled" stage is internal to Chrome, where it checks its cache to see if it can use the last response instead of making the request https://developers.google.com/web/tools/chrome-devtools/network-performance/reference#timing-explanation – Robin Nov 21 '18 at 15:13
  • I'm seeing the same behaviour when I change the POST to be a GET instead. – Robin Nov 23 '18 at 13:27
  • OK I've now found that if I rapidly fire off requests (when connected on 4G on Chrome) it will be successful, until I stop firing for a period (say 5 seconds) then it will exhibit the symptoms above. Then a subsequent request will get through. I'm thinking it might be related to the keep-alive settings on the server somehow? – Robin Nov 23 '18 at 14:16
  • This seems to have something to do with the KeepAlive configuration in Apache - if I fire off the requests before the timeout has elapsed it works fine. If KeepAlive finishes, the first request will stall for up to several minutes then fail with ERR_TIMED_OUT, and subsequent requests will then work successfully until the KeepAlive timeout expires. Is there something I could be doing wrong to cause this? – Robin Nov 26 '18 at 13:02

0 Answers0