This is problem only occurs in two developer PCs out of eight used by my team developing on GCP. Some of the team, when they launch the Google Cloud Shell Editor, see the editor load normally, while others see a spinner and the message
index.js:123 WebSocket connection to 'wss://970-dot-11840774-dot-devshell.appspot.com/services' failed: Error during WebSocket handshake: Unexpected response code: 404
in the Developer Tools console log when using Google Chrome.
We also see:
VM94663 bundle.js:67 Error: Connection timeout
at VM94663 bundle.js:67
Problem is not resolved by:
Restarting browser after clearing cache
Running Google Cloud Shell Editor in Incognito Mode
Running it in Firefox instead
Starting the session in "Safe Mode", an option in the hamburger menu for Cloud Shell
I've tried the other fixes in similar posts here but they don't work. Any ideas?
I have two suggestions that might help:
Have you tried to using a different network? Might be an issue with Network Firewalls
Verify if there's no policy blocking gRPC protocol, that is used by the console, either on the network firewall or in the local machine settings
Related
I'm using a Microsoft add-in for Powerpoint called 'Web Viewer' (it's just an iframe, you insert a URL, it displays it in the slide).
I inserted a webpage that uses Socket.IO, and I'm seeing it is not able to connect to the server (even the long polling it's falling back on is not working).
Clearly this is not an issue with the add-in: Any ideas what is going on here?
I tested on Mac 10.13.4 (latest) / Powerpoint (16.12, Office 365 Home) (latest).
The same webpage works in an iframe in the latest Chrome, Firefox, Safari, IE11, so I'm thinking something wonky is going on with the embedded (Webkit) browser that Powerpoint is using on Mac.
The general request flow is:
Browser -> AWS ALB (with stickiness enabled) -> Nginx -> Node
UPDATE
Looked into this further, and having tested other pages that use Socket.IO, I think the only difference in their setups and here is the ALB.
Even with stickiness enabled, the load balancer is clearly seen (in the logs) passing traffic between all EC2s. This leads me to believe the cookie they use is either not being set or not being passed with the requests.
First of all, based on this github issue it should be possible to open a websocket.
There might be a problem with using the unsecure ws://. I know that officejs rejects all requests to http:// and forces you to use https:// with a secure certificate. So they might do the same with WebSockets and force you to use wss:// with a valid certificate.
You can test this more easily in Power Point Online with Chrome. The addin is the same but you get much better error logging in the Devtools Console (hit F12). If it's asecurity issue there should be an error message indicating it.
I had the same issue and S.Freederle is correct. Now I'm able to use socket.io via ngrok to create a secure tunnel (HttpS) to connect to my server and emit the data to my client side in office add-in.
We have recently started experiencing problems with communication with our ESXi devices through CIM, TCP port 5989. At first we thought this was related to our remote monitoring and maintenance tool, N-central by SolarWinds N-able, however we now have reason to believe that this is not the case.
The reason for why I believe this is a Vmware is that I've attempted to reach one of the ESXi devices at 5989 by browsing to it with Internet Explorer. These attempts have all resulted in the HTTP error message 501/505 Not Implemented.
I have already attempted to browse to the page with HTTP 1.1 both enabled and disabled in Internet Explorer, no change. I've tried with and without compatibility view, no change. I've tried Google Chrome, I only get a blank page and when I check the response from the server Google Chrome just says "Failed to load response data."
Is anyone able to assist me in figuring out what is wrong, and fixing the error(s)? Please do let me know what information is required to best troubleshoot this issue.
I may misunderstood of your question;
the port 5989 descripted here in vmware website:
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2039095
vcenter server should access the esxi host with this port(CIM XML transactions over HTTPS), the error code 501/505 means that the esxi host did not recognize your client(which you use browser try connected to).
if you can pretend the agent to be vcenter, I guess you can fix the problem.
The webservice isthrowing the following error when i browse from IIS:
Server Application Unavailable
The web application you are attempting to access on this web server is currently unavailable. Please hit the "Refresh" button in your web browser to retry your request.
Administrator Note:
An error message detailing the cause of this specific request failure can be found in the application event log of the web server. Please review this log entry to discover what caused this error to occur.
In event viewer, I am getting the following message:
Failed to execute request because the App-Domain could not be created. Error: 0x80131509
For more information, see Help and Support Center at http://go.microsoft.com/fwlink events.asp.
I'm not able the understand the the problem actually is and how to resolve this. please help me.
I have found a very good article that worked for me:
https://askgif.com/blog/148/i-m-getting-error-server-application-unavailable-in-iis/
There seems to be a problem with your IIS installation, specifically, the Application Pool associated to your website. This could be because ASP.NET is not installed properly.
Please try the following:
Remove your website and application pool and recreate them
Install ASP.NET - run this command: %windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe–i as an Administrator.
I have a web service running under IIS7 on a server with a host header set so that it receives requests made to http://myserver1.mydomain.com.
I've set Windows INtegrated Authentication to Enabled and everything else (basic, anonymous, etc) to Disabled.
I'm testing the web service using a powershell script, and it works fine when I run it from my workstation against http://myserver1.mydomain.com
However, when I run the same exact script on the IIS server itself, I get a 401-Unauthorized message.
In addition, I've tried installing the web service on a second server, myserver2.mydomain.com. Again I can call my test script fine from BOTH my workstation and from myserver1.
So it seems the only issue is when the client is on the same box as the web server itself - somehow the windows credentials are not being passed or recognized.
I tried playing with IE settings on myserver1 (checked and unchecked 'Enable Windows Integrated Authentication', and added the URL to Local Sites). That did not seem to have an effect.
When I look at the IIS logs, I see the 401 unauthorized line but very little other information.
I see basically the same behavior when testing with IE (v9) - works from my workstation but not when IE is running on the IIS server.
I found the answer after several hours:
By default, there is something called a LoopbackCheck which will reject windows authentication if the host header used for the site does not match the local host's name. This behavior will only be seen when the client is on the local host. The check is there to defeat possible reflection attacks.
More details here:
http://support.microsoft.com/kb/896861
The kb item discusses ways to disable the Loopback check, but I ended up just switching from using host headers to ports to distinguish the different sites on the IIS server.
Thanks to those who gave assistance.
Try checking the actual credential that is being passed when you are running on the server itself. Often times you will be running on some system account that doesn't have access to the resource in question.
For example, on your box your credentials are running as...
MYDOMAIN\MYNAME
and the server will be something like...
SYSTEM\SYSTEM_ACCOUNT
and so this will fail because 'SYSTEM\SYSTEM_ACCOUNT' doesn't have credentials.
If this is the case, you can fix the problem in one of two ways.
Give 'SYSTEM\SYSTEM_ACCOUNT' access to the resource in question. Most people would avoid this strategy due to security concerns (which is why the account has no access in the first place).
Impersonate, or change the credentials of the client manually to something that does have access to the resource, 'MYDOMAIN\MYNAME' for example. This is what most people would probably go with, including myself.
when i try opening http://127.0.0.1:8500/test.com
I get
500 There is no web application configured to service your request There is no web application configured to service your request
when i try opening http://127.0.0.1:8500/CFIDE/
I GET THE same error
Kindly guide me to solution.
It means the server did not fully start. The JRun container started and was able to accept an HTTP Request via its internal webserver port, but then the ColdFusion Server inside JRun was not fully deployed or not deployed at all.
The startup events in /path/to/coldfusion8/runtime/logs/coldfusion-event.log and /path/to/coldfusion8/logs/server.log will contain details about what failed during ColdFusion startup.
You will probably not make sense of the events as they are usually somewhat cryptic. Please post log contents for further diagnosis.