I have an ASP.NET MVC 4 app (.NET 4.5) and SIgnalR works fine with forms-based authentication (hosted via IIS/IIS Express)
As soon as I change the app to windows-integrated authentication (<authentication mode="Windows"/> in "web.config") it stops working.
jquery.signalR-2.2.2.min.js:9 WebSocket connection to ws://localhost:51030/signalr/connect?transport=webSockets&blhablahblah failed: Error during WebSocket handshake: Unexpected response code: 403
After adding the [Authorize] attribute to my hub, the error changes to
WebSocket connection to ws://localhost:51030/signalr/connect?transport=webSocketsblahblah failed: HTTP Authentication failed; no valid credentials available
Other parts of the app are working just fine, windows-auth is enabled on the server and works, etc. etc.
How do I solve this?
And if it is unsolvable for some reason (it could be Chrome not supporting windows auth on websocket connections or something else) - why doesn't it fall back to non-websocket protocol? and how do I force the fallback?
UPDATE: I created a github issue https://github.com/SignalR/SignalR/issues/3953. The problem is not that I can't connect. The problem is that I cannot handle the error to fall back to another transport. Neither .fail() not .error() are being invoked. Try-catch doesn't help either.
Update from 2020: looks like Chrome now supports NTLM on WS-connections, not an issue any more
...10 hours later after asking the question...
Partially solved (answering my own question)
After playing with it I can confirm, that adding the [Authorize] attribute to my hub (or alternatively, adding GlobalHost.HubPipeline.RequireAuthentication(); to your "Startup.cs") actually does help. It does fall back now to an alternative transport, even though the error is still thrown into the browser's console.
You can also specify which transport it falls back to, by calling:
$.connection.hub.start( { transport: ['webSockets', 'longPolling'] });
in case you don't like the default priority (I guess, "hidden iframe" is the default second option).
The reason
The error is caused by Chrome, it does not support NTLM on websocket connections. Funny enough, IE, MS Edge and Firefox do support it ("Chrome is the new IE" huh).
There's an open issue in Chromium bugtracker for this here https://bugs.chromium.org/p/chromium/issues/detail?id=423609 if anyone wants to add any input to Chromium devs.
I too was experiencing this error, but only when developing locally using http; I think Chrome doesn't like unsecured ws:// connections. Once I deployed to server with secure https connection, the WebSocket connection was upgraded to wss://, and Chrome stopped complaining, worked fine with WebSockets--didn't have to fall back to other transport.
tl:dr; Make sure to use https for your site.
Related
I'm using IIS 10 server as a gateway for Node.js server.
When client calls download files such as zip file, IIS server download Node.js server internally with HTTP protocol, and then it pass to client with HTTPS.
But in Chrome web browser, It shows error
net::ERR_HTTP_1_1_REQUIRED with status 200, and when I try to download again it works well until I clear the caches.
In Firefox, it returns status 200 too, but nothing's happen.
In Microsoft Edge and IE11 works well too.
I've set enough timeout and buffer size in IIS.
May Chrome and Firefox go wrong at HTTPS - HTTP connection or something else?
There may be some extensions in your Firefox and Chrome that can cause this error. This error means a browser extension blocked the request. The most common culprit is an ad blocker like AdBlock Plus. In short your requests to server have been blocked by an extension. so you can try to disable these extensions and try again.
It seems that the .NET Core team found a related issue and provided a workaround.
Perhaps the same can be applied with other frameworks.
https://github.com/dotnet/aspnetcore/issues/4398
Apparently, when doing an ajax request from a browser, it will sometimes send an OPTIONS request before the real request with a 204 status code which causes the problem.
For me, it seems to have solved my problem to return the file with a response content-type of "text/plain" instead of "application/octet-stream"
I'm not really sure why it works, it just does.
I am working on an API in .NET core 2.
Everything works great when testing on https://localhost:44333, but when trying on http://localhost:44333 it does not work anymore. It just loads, and loads, and loads.... Nothing to see in the logs or anything like that.
The thing is, I need to get it working on HTTP because I want to try it on my phone in the app. So I use iisexpress-proxy to proxy it. This works when I can access the API on HTTP, but it doesn't work with HTTPS.
So therefor I need it to work with HTTP, but I have no idea why it does not work on HTTP. All my previous projects worked fine on HTTP and for some reason this one does not. I have looked in my startup if it might be forced or something like that, but I cannot find any...
You probably need more information than this, but I don't know what you need, so If you ask in the comments I will provide some more information/logs/code you name it.
The http version will be served on a different port. You'll need to look at your project properties to see which port it's being served on.
Just as some background:
There's effectively a client-side and server-side component to SSL. The http or https is the client-side component. That means the browser or other web client will either try to negotiate a secure socket or not, respectively. The server-side component is the port binding, which will either be a secure socket or not.
The forever-loading is because your client is trying to make a non-secure request, but the server's socket is attempting to negotiate SSL. It's like one person speaking Chinese and the other speaking Spanish. They're both communicating, but nothing gets accomplished.
I currently the latest zeppelin source running in a master server with HDP 2.5, System is CENTOS 7.2. I have also a worker server. Under the master server, the following entry inside the Zeppelin log:
NotebookServer.java[onMessage]:169) - PING message: invalid ticket c89ae223-65ac-2222-1111-fa46122bafec != fbffe895-1111-1111-8d50-67c2b8fbfbf6
and on the browser I can see a JS error with invalid :
JSESSIONID=6c89ae223-65ac-2222-1111-fa46122bafec
So, If I restart the browser in incognito mode the issues does not happen in the browser, but I can still see the log entry in the server. It will remain there until I restart all services and kill all connections.
I ended up disabling the authentication and now the issue is gone (but I have no authentication)
On the other side, the server is behind 2 proxies, one faces the internet and the other a LAN. I am using a similar proxy configuration as recommended by the guide, the only difference is that I am using a url rewrite.
so, the question is: how can I avoid that issue? How can I flush the current sessions of Zeppelin and force a re-login?
Thanks,
Normally that error happens when your session/ticket has expired and you still have Zeppelin tab open and it keeps sending ping messages with old ticket. So for example, when you logged in incognito mode, your old ticket will be invalidated, and if your old tab is still open you'll be getting that error on server. For more details, it would be nice to have your scenario from time your start Zeppelin server in order to reproduce same error case. Possibly some related issues could be under ZEPPELIN-1200, and ZEPPELIN-1298.
Update: it's been addressed under ZEPPELIN-1298
In Flex 3 application I use HTTPService class to make requests to the server:
var http:HTTPService = new HTTPService();
http.method = 'POST';
http.url = hostUrl;
http.resultFormat = 'e4x';
http.addEventListener(ResultEvent.RESULT, ...);
http.addEventListener(FaultEvent.FAULT, ...);
http.send(params);
The application has Comet-architecture. So it makes long running requests. While waiting a response for this request, other requests can be made concurrently.
The application works in most cases. But sometimes some clients get HTTP request error executing long running request:
faultCode:Server.Error.Request
faultString:'HTTP request error'
faultDetail:'Error: [IOErrorEvent type="ioError" bubbles=false cancelable=false eventPhase=2 text="Error #2032"]. URL: http://example.com/ws'
I think it depends on user's browser.
Any ideas?
I experienced the same problem when I sent longer (3-4K!) parameter in HttpRequest. As soon as I sent smaller ones it worked (without refresh, reload or anything). I do not know if there is a limit on client side or on web server side of the length of parameters you can send but definitely this causes the issue.
url limitations may cause it
This error appears very generic and I would suggest trying to collect more information and sharing it regarding the issue.
This post appears similar to your situation.
This post might help you find more debugging information which would be helpful.
Which clients are affected?
Can you capture the http status code or the traffic being sent using Charles, Wireshark, or similar?
Try listening for the HTTP-status of the request, using flash.events.HTTPStatusEvent.HTTP_STATUS
That might give you some more info about what's going wrong.
I was going to open another question on essentially the same topic, but I figure two unanswered questions is worse than 1.
I get a similar intermittent issue from some users of a Flex application we have, but with some slightly different symptoms. The full range of information I can provide is:
It occurs on short (10ms) requests as well.
It appears to occur randomly.
The connection is over SSL.
It only occurs for users of IE, not for users using FireFox.
Once it occurs, users inform me they need to shut down IE and restart it (some users say they need to reboot, but I think that's less likely than just an IE restart). It appears to require a few minutes to reset itself.
It does not appear to affect the rest of the user's internet connection -they can continue to use other IE windows.
Once it occurs, it appears that no HTTPService request from the flex application will work.
It occurs (apparently) only for a small subset of users. Initially it
seemed to be due to their physical distance from the main server, but this no longer
appears to be necessarily the case (though it could be connection quality).
I'm not clear on what version of Adobe Flash the users are running.
Code was built with Adobe Flex 3.4 (linux)
The application does a wide range of requests, many in parallel though I've not been able to reproduce the problem.
Users do suggest this error occurs after they have come back to the application after a few minutes.
There appears to be no related server side request entry in the server logs, suggesting the request never reaches the server (possibly never leaving the client).
The server responds to all requests with the relevant cache headers to turn of IE caching.
The current workaround we have is to request users run the application in FireFox.
Full dump of the error is:
HTTP Status Code: null
Fault Code: Server.Error.Request
Fault Error ID: null
Fault Detail: Error: [IOErrorEvent type="ioError" bubbles=false cancelable=false eventPhase=2 text="Error #2032"]. URL: https://my.server/url
Fault String: HTTP request error
Fault Name: Error
Fault Message: faultCode:Server.Error.Request faultString:'HTTP request error' faultDetail:'Error: [IOErrorEvent type="ioError" bubbles=false cancelable=false eventPhase=2 text="Error #2032"]. URL: https://my.server/url'
Root Cause: [IOErrorEvent type="ioError" bubbles=false cancelable=false eventPhase=2 text="Error #2032"]
Many people have mentioned error 2032, a few even mentioning intermittent errors under IE only, but there are no mentions of the solution. If I ever find one, I'll update my post here.
Update
After talking to a user as this occurred, we found the following:
The user could open a new tab in IE, and load the same flex application up fine - so no internet connectivity problems.
The user could, in the tab with the flex app where the error occurs, load up google.com - so there appears to be no connectivity issue related to that specific tab.
The user could copy the address from the tab with the broken app into another tab, and the flex application would load.
The user could, after loading google.com in the tab where the flex app broke, copy in the flex app URL again, and immediately get the problem.
It appears that in my particular application, my flex app manages to break the flash plugin/VM to such an extent that after the break, no further requests to the URL are allowed.
I am so completely stumped by this I'm at the point of suggesting users use FireFox, or wrapping the application in an Air package.
I had somewhat the same problem here but with a Flash (Web - Flex 4.1 SDK) application.
after trying out a huge assortment of solutions we narrowed we finally came up with one that works pretty reliably for all systems, including newly installed machines.
A. add global event listeners at the root (or stage) of the application, on flex preinitialize stage.
IOErrorEvent.IO_ERROR
IOErrorEvent.NETWORK_ERROR
HTTPStatusEvent.HTTP_STATUS
ErrorEvent.ERROR
SecurityErrorEvent.SECURITY_ERROR
if an error is cought - event.preventDefault();
B. add event listeners on every loader used in the App for the following errors:
IOErrorEvent.IO_ERROR
SecurityErrorEvent.SECURITY_ERROR
HTTPStatusEvent.HTTP_STATUS
*to attempt recovery, like falling back to an external interface call...
C. place all the SWZ files from the bin-release folder together with the SWF file in the same path on the server you use to deliver your App.
in my case these are the files needed:
sparkskins_4.5.1.21328.swz
spark_4.5.1.21328.swz
textLayout_2.0.0.232.swz
rpc_4.5.1.21328.swz
osmf_1.0.0.16316.swz
framework_4.5.1.21328.swz
* to discover this i used Chrome developer console to see which errors occur on the page and discovered a chain of 404s when the app tries to download these files.
D. have a properly configured crossdomain.xml policy file which includes the allow http request xml tag.
<allow-http-request-headers-from domain="*" headers="*"/>
replace the * as needed in your particular case.
Cheers
Sounds like you might have more connections going out then the browser supports. Do you know exactly how many open connections exist at the time of the error?
Different browser allow different numbers of simultaneous open connections. IE 6,7,8 all allow different amounts: http://support.microsoft.com/kb/282402
Firefox: http://www.speedguide.net/faq_in_q.php?qid=231
I've had this exact issue happening in my Air app. I eventually realized that I had accidentally set the urlrequest.idleTimeout to 10. This timeout is actually in milliseconds and my webserver is local, so if I sent no parameters (no get or post) to my local server it would work. Whenever I sent any parameters along with the request of course it would fail because my script took longer than 10ms to run and return the data.
You may want to pay attention to slow loading scripts. You can debug by just forcing some static output and then stop that page from executing further. In my php page I put:
<?php
echo "hello=hi";
die();
?>
Also, make sure to debug it within the sandbox limitations. I am using a self-signed ssl cert and there are a lot of warnings when trying to connect to my local test webserver.
Hope that helps!
Getting sporadic errors from users of a CMS; Ajax requests sometimes result in a "501 Method not implemented" response from the server. Not all the time; usually works.
Application has been stable for months. Users seem to be getting it with Firefox 3. I've seen a couple references via Google to such problems being related to having "charset=UTF-8" in the Content-type header, but these may be spurious
Has anyone seen this error or have any ideas about what the cause could be?
Thanks
Ian
You may want to check the logs of the server to see what's causing the issue. For example, it might be that these requests are garbled, say, because of a flaw in the HTTP 1.1 persistent connection implementation.
Try this
Try clearing your cookies and your cache
Type about:config into the URL bar, list of configuration settings for Firefox
Locate the setting for 'network.automatic-ntlm-auth.trusted-uris'
Set the value of names of the servers to use NTLM with.
Locate the setting for 'network.negotiate-auth.trusted-uris'
Set the value of names of the servers to use NTLM with.
network.automatic-ntlm-auth.allow-proxies = True
Restart Firefox - Test URL to application
The problem occurs as your app is not running on the same domain as your service. You need to configure your Server to accept those calls by adding the 'Access-Control-Allow-Origin' Header.