XHR requests fail after KeepAliveTimeout has elapsed only when using 4G connection
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
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
add a comment |
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
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
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
add a comment |
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
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
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
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
ajax apache google-chrome keep-alive tethering
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
add a comment |
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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