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 EMPT… (read more)
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:
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.
Any ideas about this would be much appreciated.