XHR requests fail after KeepAliveTimeout has elapsed only when using 4G connection












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.










share|improve this question




















  • 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 developers.google.com/web/tools/chrome-devtools/…

    – 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















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.










share|improve this question




















  • 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 developers.google.com/web/tools/chrome-devtools/…

    – 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












0








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.










share|improve this question
















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.







ajax apache google-chrome keep-alive tethering






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 27 '18 at 16:24







Robin

















asked Nov 21 '18 at 15:01









RobinRobin

16119




16119








  • 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 developers.google.com/web/tools/chrome-devtools/…

    – 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
















  • 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 developers.google.com/web/tools/chrome-devtools/…

    – 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










1




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





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 developers.google.com/web/tools/chrome-devtools/…

– Robin
Nov 21 '18 at 15:13







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 developers.google.com/web/tools/chrome-devtools/…

– 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





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





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







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






active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53414856%2fxhr-requests-fail-after-keepalivetimeout-has-elapsed-only-when-using-4g-connecti%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53414856%2fxhr-requests-fail-after-keepalivetimeout-has-elapsed-only-when-using-4g-connecti%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Costa Masnaga

Fotorealismo

Sidney Franklin