We Keep Coding

net::ERR_SPDY_PROTOCOL_ERROR in chrome

I'm using JS-autocomplete which is working fine in the local environment, but in Live environment, initially autocomplete works properly, but after 3-4 attempts I'm getting net::ERR_SPDY_PROTOCOL_ERROR in the console (only in one page).
This is not the case for all pages, other pages have the same autocomplete which is working properly, I have tried in incognito mode and some other browsers, but getting the same error
I have tried following methods
Cleared temp files, cookies, and caches Flushing SPDY Sockets using chrome://net-internals/#sockets
Updated browser Flushing DNS and Renewing IP
but these attempts did not solve my problem
Note: I have not installed any Antivirus
Snapshot of Network panel

Try following two things :-
Use http2 protocol for loading your resources as well and for the auto-complete API.
Use unique identifier for your auto-complete API(like &t=(new Date()).getTime())

Error when loading Google oauth2 javascript api while logged into multiple Google accounts

I am trying to use the Google+ sign in button via the javascript api. Everything works fine on Windows computers and Chromebooks, but it fails on every Mac that I have been able to test it on. (see update 2 below, this is not actually a Mac problem)
When the initial Google api file is loaded (https://apis.google.com/js/client:platform.js) an error is logged in the console, saying that https://accounts.google.com/o/oauth2/iframerpc?scope=email+profile&response_type=token+id_token&login_hint=[HINT]&origin=[ORIGIN]&action=issueToken&ss_domain=[SS_DOMAIN]&hd=[HD]&client_id=[CLIENT_ID]&hl=en&from_login=1&as=[AS] returned a server side error. When I pull up the URL in the browser directly, I get a JSON object with one property:
{"error":"internal_server_error"}
This only happens on Mac computers (Google Chrome, haven't tried another browser), and it all works fine in an incognito window. (see updates below, Mac is not the problem)
UPDATE:
I have determined that this only happens when a user is signed in to multiple Google accounts; and moreover, only when the user is trying to authenticate to my website using one of the accounts that is not marked as the "default" account (a.k.a. the first Google account that they signed into).
This also happens on Safari.
UPDATE 2:
This is NOT a Mac issue, it just happened to be coincidence that the 5 or so users that this affected were all using Macs (even though our company probably only has 10 out of 200 users that use Macs, and the only people reporting this error happened to be using Macs).
The real issue happens on any computer, but ONLY when the user is signed in to multiple Google accounts and tries to authenticate to my site using a one of their Google accounts that is not the "default" account.
P.S. Thanks to #brenjt for the subject update, which turned out to be very accurate.

Thanks for the report, Blair. It took us a while to dig into the root cause of this one, and were assisted by your comments. Assuming it's the bug we think it is - we pushed a fix to production around last Wednesday that resolves the issue. Please let me know if that's not the case!

status code 12004 while doing a service call

I am doing a service call in my javascript which return xml data using xmlHttpRequest.My service call is working in chrome and firefox perfectly and getting the data(it is a https call).But when i try the same with IE11 it is giving status code 12004 .I tried searching it on google i found only one answer saying it means ERROR_INTERNET_INTERNAL_ERROR.
I tried opening fiddler to see the request but when i open up fiddler service call is working fine,but when i close fiddler it is showing same error code.

From the WinINET constant ERROR_INTERNET_INTERNAL_ERROR it appears that the issue is related to the WinINET API which I assume is being used by IE to enable itself to interact with HTTP protocols (including HTTPS) to access Internet resources
http://msdn.microsoft.com/en-us/library/windows/desktop/aa385465(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383630(v=vs.85).aspx
If you really wanted to go deeper and understand the issue, try to download STRACE which is socket/SSL tracer designed to generate LOG for Internet Explorer:
http://www.microsoft.com/en-us/download/details.aspx?id=7643
On a quicker check, you might want to see if your Windows updates is up-to-date to make sure your wininet.dll is the latest and greatest

WebSocket on IE10 giving a SecurityError

I am currently developing a website under IE10 (on Windows 8), using WebSockets in JavaScript. It runs fine under Firefox 18 and Chrome 25, but on IE10 I get a SecurityError when I establish the connection.
What I am doing seems pretty straghtforward :
websocket = new WebSocket('wss://hello.dev.mydomain.net');
But IE doesn't like it :
SCRIPT5022: SecurityError
The script is on "https://test.dev.mydomain.net" (not the real address obviously).
What bothers me is that if I just double-click the file on my local computer (e.g. file://...) it just works. Even worse: if I use fiddler to monitor HTTP traffic... it also works. Whereas there seems to be no connection at all without fiddler, as detailed in the API's specs. (See below.)
Judging by websocket spec, the exception should also appear on Chrome/Firefox... but it does not. So I doubt it has anything related to HTTP/HTTPS. In any case, I am using a wsS socket on a httpS page... Moreover: when I replace the wss address by another valid server found on an online example, it works.
I don't know if this is relevant, but the IP from test.dev.mydomain.net is 10.14.x.x where hello.dev.mydomain.net is 194.247.x.x. I don't know if it could trigger some kind of security on IE only...
One more thing: I have a certificate for *.dev.mydomain.net, IE does not seems to have problems with it. The script originally resides on a server called my.name.dev.mydomain.net, but since I am accessing it from another URL (I got a redirect since we first thought it could have been some kind of Same Origin Policy issue), I don't see how it could matter. At least I hope it does not...
Any idea is welcomed.
EDIT: adding the sites to the trusted zone does not work either.

It looks like IE throws a SecurityError if you're trying to open a websocket on a local (intranet) domain. To overcome this, you may disable IE's automatic algorithm for recognizing local sites. This can be done in Tools > Internet Options > Security > Local Intranet > Sites.
Uncheck all checkboxes (or only a particular one, if you know how exactly your domain did end up in intranet ones).
Note that IE uses (among other things) its proxy settings to determine local sites: if your domain is listed as excluded from proxying in proxy settings, then it will probably be treated as intranet one. This is why WebSockets work if you enable Fiddler: it modifies IE proxy settings and thus the list of intranet sites changes.

I had this problem in Windows7/IE11 after applying a security patch. For Windows10/Edge is the same story.
As this is a local websocket (ws://localhost) you have to add ws:\\localhost\ to Internet Explorer configurations (Tools > Internet Options > Security > Local Intranet > Sites > Advanced).
In Windows 10/Microsoft Edge you will find this configuration in Control Panel > Internet Options.
UPDATE
The address of your webapp (https://test.dev.mydomain.net) must be added to the local intranet zone too. Note that in the image the webapp address should be added.

Well, my question wasn't that successful, so I'll post the "workaround" I found.
I got another address for the website, in 194.247.. too. This, magically, solved it. Guess IE doesn't like mixing local and external stuff and watches the IP.
Anyways, I hope this may come in handy to anyone who's got the same issue.
If you have a solution to solve the "real" issue by configuring IE, let me know :)
Cheers,

Browsers has a websocket limitation. For example Internet Explorer has default limit of websocket connections set to 6 per host header name. the same limitation is set for WinForms WebBrowser component.
The solution is to add values under key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WEBSOCKET_MAXCONNECTIONSPERSERVER in registry. Just add DWORD value with executable name , for example iexplore.exe (or your application executable name if you use Web browser component) and set value from range 2..128
Second option how to solve SecurityException is to create multiple subdomains.

The client hostname/IP Address should be same as server IP/Hostname thats listening to otherwise you would get the above error.
1) Make sure whether server hostname configured to listen at IP/localhost etc andif not explicitly specify the hostname ast server
2) use the same hostname in the client. THis will solve the issue. It worked for me...

I encountered the error (although it did not say the SCRIPT5022 part, rather it just reports "ScriptError"). I got around the issue by clicking on "Trusted Sites" and then adding the machine hosting the remote websocket. Note, to add to trusted sites,
I had to supply the address without the "ws://" part (like just mymahcine.mydomain.com)
I had to uncheck the box that says "Require server verification https:// " option.
After I was done adding the domain, I re-checked the box "Require server verification (https://). I would recommend everyone to do the same. Unchecking the box is only a workaround to add sites that don't begin with https (rather ws:// in my case)

I had the same issue at one of my customer's environment.
It turned out that they had a proxy configuration that did not allow the connection to the WebSocket endpoint directly and did not support the WebSocket protocol.
The temporary solution was to disable using the proxy and everything started working. The long term solution is to edit the proxy's configuration (.pac file) to exclude the address of the WebSocket endpoint.
To disable the proxy, go to: Internet Explorer Options > Connections tab > LAN settings button > un-check Automatically detect settings.
Hope this helps someone.

In addition to making sure that the internet zone is not localhost (as in above answers), ensure that if https is used, then wss should be used.
This is not an issue in other browsers, but IE is abit more finicky.

Why doesn't the GeoLocation API javascript code works/loads on my computer

I have an HTML5 page loaded on server along with a geolocation script. The code is working and has no errors. It shows the position and map the user. Right now, it's working well for everyone else and i also tried the same on other PC and it works. But, when i visit the page on my Chrome browser, nothing shows up. Why is that happening? Why can't it locate me and map me? I have Windows 7 OS running the latest Chrome and using data-card for internet.
This is the LINK
On the other hand, the Google page accurately shows my location on the left bar side

That page detects my location correctly in Chrome 17 (dev channel). I do see a JavaScript error, however: "Uncaught ReferenceError: geocoder is not defined" on line 81 of myLoc.js. Taking a quick look at the code, it doesn't appear to be defined anywhere. Have you perhaps forgotten to include a file?

I experienced the same issue with geolocation script. It seems to be an issue with Chrome specifically blocking the uri starting with "file:///" for security reasons.
See related articles:
http://groups.google.com/a/googleproductforums.com/forum/#!category-topic/chrome/give-feature-feedback-and-suggestions/E0yx7wne-RI
http://groups.google.com/a/googleproductforums.com/forum/#!category-topic/chrome/report-a-problem-and-get-troubleshooting-help/pNcftbZTN1E
HTML 5 Geo Location Prompt in Chrome

Check in your chrome, in settings -> advanced -> privacy (content) -> localization if you allow web pages to check your location (this menus can be named a bit different, I'm checking on Polish Chrome).
You say nothing shows up and the question to allow web page to check location should show up (this happens by me).
Another thing, geolocation is checked by Wi-Fi if available, determine it by your IP may be quite inaccurate.