I recently deployed a node.js based site into load balanced servers(windows).
(Not sure if Node.js or load balancer matters in the case, but want to share the information)
When I hit the url in Chrome, I sometimes get ERR_Connection_Reset error:
For example: mysite.com/bower_components/jquery/dist/jquery.js net::ERR_CONNECTION_RESET
But if I try to hit mysite.com/bower_components/jquery/dist/jquery.js in browser, it works. Which means the path doesn't have problem.
When I hit the url in IE, I sometimes get XMLHttpRequest: Network Error 0x2eff, Could not complete the operation due to error 00002eff.
I've been scratching my head for days, any help will be appreciated!
What version of node are you using? This patch fixed a problem with idle sockets throwing ECONNRESET errors and it shipped in 4.4.0 and 5.4.0, upgrading fixed the issues for me.
Related
Recently, I am getting the following message on chrome console;
WebSocket connection to 'ws://evo15:4008/?stream' failed: Unknown reason
It's getting more and more and it's somehow annoying and I have to open a new tab or restart chrome every time to get back to normal websocket connection. How can I debug it? Unfortunately, I cannot reproduce it yet. My chrome version is Version 77.0.3865.75 (Official Build) (64-bit)
Update 1: I think you could reproduce it by closing the connection for a long time (I don't know the exact time) from server side and then open it and try to connect to it (client trys to connect every 1 sec). Then it will happen. So I guess there is an expire time or a limited number of tries to connect somewhere.
Update 2: It happens after 256 tries of reconnection.
WebSocket connection to 'ws://evo15:4008/?stream' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
After seeing 255 of this error on console, you will see the first error and cannot reconnect. So I think there is a 8 bit limit somewhere that I am missing
Looks like someone just filed this as a Chromium (v77) bug. See issue tracking it here.
Update 1: As noted in the issue tracker and comments below, this should now be fixed in the latest stable release, which is being rolled out now (2019/10/11).
Update 2: Despite the bug being marked as fixed/closed in monorail, canary (80.0.3977.4) still appears to have this behavior. As others have noted there is a global limit of 255. However, the fact that connections opened by JS don't get closed/reset when the page is refreshed still seems like a bug to me.
For some very very very odd reason in my computer the websocket connection was considered as an ad by AdBlock.
Try to disable AdBlock and see if it works.
On Chrome and Firefox I sometimes get the following error err_spdy_protocol_error
once I call the following website https://checkideas.com/.
I have researched on this topic on the internet and on this platform as well. I also found a working solution. Once I delete all the cookies and reload the webpage the error does not emerge.
So if you click on the website for the 1st time it will definitely work. But once there are number of cookies given the website cannot always be called. This is only the pattern I have identified so far. However I would like to have a sustainable solution.
What do I have to do to avoid this issue so that this issue does not occur? What is the source of the error?
Unfortunately following responses on similar questions did not answer my question:
Console errors. Failed to load resource: net::ERR_INSECURE_RESPONSE
What mean ERR_SPDY_PROTOCOL_ERROR in nginx?
I also cannot identify any issue with the certificate.
This error is related to the SPDY Protocol or an antivirus setting.
Updating to a later version of the browser should help fix the error (Google Chrome and Mozilla have dropped support for the SPDY Protocol.
This article contains methods that should help you fix the ERR_SPDY_PROTOCOL_ERROR
on Google Chrome or Mozilla.
I'm getting this error 504 (Gateway Timeout) 6 time and again while trying to view a file. It's weird that this doesn't happen always, the viewer gets rendered as usual but sometimes we get this error.
Previously I thought it was rather a cache or connection issue. But this happens even when we have a stable internet connection. And sometimes it persists even after doing hard refresh multiple times. So, it's weird.
I just want to know reason why this error actually occurs.
We're using viewer version v2.8 here.
The viewer renders this message:
And here is the exact error message we get in the console:
I cannot tell what's wrong without some code to look at...
But it seems that you are using V1 and would recommend you migrate to V2. See this blog post with more details on the migrations. There are several benefits! :-)
Also, consider using the latest viewer version, 2.10 (as of September, 2016).
I'm working on a little project to create an offline application using HTML5, IndexedDB and Angular. I've been testing the application cache functionality by toggling air plane mode on my laptop and so far so good.
However, my requirements are that the application should be availble when the user is not connected to the VPN instead of not connected to the internet. I'm testing this by starting/stopping the applciation hosted in IIS, so I might still have a connection to the internet but not to the server that hosts the application. In this scenario I always get the error (in Chrome) "Applicaion Cache Error event: Manifest fetch failed (6)". FireFox doesn't give an error and IE just says Fatal AppCache Error.
I know why I get the error (= the manifest file cannot be fetched from the server), I'm just wondering if there is anything I can do to avoid the error? I've been looking at ways to override or prevent the swapcache/update events but no luck. Any idea if this can be fixed and how?
I have a Chrome Extension, Requestly which allows you manipulate HTTP Requests. 3-4 Users have faced an issue where Searching in Omnibox is Crashing the Google Search Results Page while rest of the pages work fine.
Please have a look at this Gif for more understanding.
Issue seems to be resolved by couple of ways:
Export Rules, Delete Rules, Restart Browser, Import Rules
Simply Restart Browser
Clearing Cache
This issue is reproducible on Ubuntu 14, Windows 8.1 Chrome 42. I have Ubuntu 12.10 Chrome 42 and I never saw this issue.
Here is the background.js code on Github. I am just wondering the cause of issue. I have used the following in my code
chrome.storage.sync
chrome.webRequest.onBeforeRequest (Blocking Option)
chrome.webRequest.onBeforeSendHeaders (Blocking Option)
I have observed another Chrome Extension, Scritsafe is facing the same issue. Details mentioned in this thread but the users are still not able to completely get rid of this bug.
One of the kind and helpful user gave me this information by enable logging while launching Chrome but I am not sure if these logs are helpful. These are the logs:
[13753:13788:0515/203052:WARNING:spdy_session.cc(2373)] Received HEADERS for invalid stream 7
[13753:13788:0515/203052:WARNING:spdy_session.cc(2373)] Received HEADERS for invalid stream 11
[133,3746404608:17:30:52.858104] Native Client module will be loaded at base address 0x0000702d00000000
[13753:13788:0515/203058:WARNING:spdy_session.cc(2373)] Received HEADERS for invalid stream 17
[13753:13788:0515/203210:WARNING:spdy_session.cc(2373)] Received HEADERS for invalid stream 55
[13791:13791:0515/173212:WARNING:ipc_message_attachment_set.cc(37)] MessageAttachmentSet destroyed with unconsumed descriptors: 0/1
Main problem is I am not able to manifest this on my machine. If I am able to manifest this, I would certainly try some random things and figure this out.
I have done enough Google Research. Now How should I approach to fix this issue ?
Edit:
Clone of this question is also available in Google Chrome Extension Forum. Simon Knott has also faced the same problem/bug.
He mentioned to avoid blocking all requests (Avoid especially XHR).