Avatar for Username

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

This thread was archived. Please ask a new question if you need help.

Request for a CSS file takes 40 seconds, only for some users: 20 secs "Blocked"; 20 secs "Connecting"

  • No replies
  • 1 has this problem
  • 1 view
llefever
llefever
more options

At first, I was debugging an EMPTY_RESPONSE issue in Chrome, but, then, I tested access to the same file in FireFox, and I saw the issue at hand: that is, instead of EMPTY_RESPONSE in Chrome (which, I figure, might involve a timeout that Chrome does but which FireFox doesn't do), I see what's shown in the attached screenshot: namely, that the request blocks for 20 seconds (trying to access an available socket, as I understand it), then takes 20 seconds "Connecting".

This seems to be something specific to the given user's machine -- maybe malware. However, I want to know more specifically what's happening. The idea is that maybe this 40 second delay in FireFox might help explain the EMPTY_RESPONSE in Chrome.

I found the following StackOverflow post: https://stackoverflow.com/questions/27740692/request-stalled-for-a-long-time-occasionally-in-chrome

From that, in particular: "If the problem occurs only when accessing a particular server, the reason might be that chrome is fetching multiple resources (like images, CSS files, etc) on parallel connections. Since, in your case, the server is on your local network, you might want to ask the server's administrator to add support for persistent TCP connections."

I've checked to be sure the app-server (WebSphere in iSeries) is configured to allow persistent connections, and that is the case (per its admin-console). The issue does occur (for those for whom it occurs) only against our iSeries WebSphere instances, not against our Windows one. So, I've suspected something in the TCP or HTTP config on our iSeries app-servers. However, only certain users have that problem. My workstation, for instance, doesn't have that problem. So, it's not clear how it could be a server-side problem.

Meanwhile, the problem does exist for at least two users outside our network. So, if it's malware, it would seem that, somehow, those two external users happen to have the same malware as certain of our internal users. However, we haven't found any malware on our internal users' machines (using Malwarebytes, etc.) -- which, though, of course, doesn't mean there isn't any there.

Also, in the attached screenshot, the file in question is from the Bootstrap third-party JavaScript library, but we're hosting the copy of it that we're using; so, it's not a matter of needing to be able to access it from a third-party server.

Any ideas about this would be much appreciated.

At first, I was debugging an EMPTY_RESPONSE issue in Chrome, but, then, I tested access to the same file in FireFox, and I saw the issue at hand: that is, instead of EMPTY_RESPONSE in Chrome (which, I figure, might involve a timeout that Chrome does but which FireFox doesn't do), I see what's shown in the attached screenshot: namely, that the request blocks for 20 seconds (trying to access an available socket, as I understand it), then takes 20 seconds "Connecting". This seems to be something specific to the given user's machine -- maybe malware. However, I want to know more specifically what's happening. The idea is that maybe this 40 second delay in FireFox might help explain the EMPTY_RESPONSE in Chrome. I found the following StackOverflow post: https://stackoverflow.com/questions/27740692/request-stalled-for-a-long-time-occasionally-in-chrome From that, in particular: "If the problem occurs only when accessing a particular server, the reason might be that chrome is fetching multiple resources (like images, CSS files, etc) on parallel connections. Since, in your case, the server is on your local network, you might want to ask the server's administrator to add support for persistent TCP connections." I've checked to be sure the app-server (WebSphere in iSeries) is configured to allow persistent connections, and that is the case (per its admin-console). The issue does occur (for those for whom it occurs) only against our iSeries WebSphere instances, not against our Windows one. So, I've suspected something in the TCP or HTTP config on our iSeries app-servers. However, only certain users have that problem. My workstation, for instance, doesn't have that problem. So, it's not clear how it could be a server-side problem. Meanwhile, the problem does exist for at least two users outside our network. So, if it's malware, it would seem that, somehow, those two external users happen to have the same malware as certain of our internal users. However, we haven't found any malware on our internal users' machines (using Malwarebytes, etc.) -- which, though, of course, doesn't mean there isn't any there. Also, in the attached screenshot, the file in question is from the Bootstrap third-party JavaScript library, but we're hosting the copy of it that we're using; so, it's not a matter of needing to be able to access it from a third-party server. Any ideas about this would be much appreciated.
Attached screenshots