I know SignalR has it's transport-method hierarchy: Websocket->Server-Sent Events->Forever Frame->Long Polling
But when I check the console in every Browser, I noticed that the transport is always Long Polling.
I'm using Windows 7, IIS Express 7.5 and Visual Studio 2013 (SignalR 2.0 of course).
I know Websocket is only supported with IIS 8, but at least SSE or Forever Frame for IE should work.
For example in Google Chrome I get this:
That means, Chrome is trying to use SSE right? But why is it cancelled?
And here a screenshot of Fiddler with Internet explorer:
It's blue... and the code is 200. (and why are there different ports? The site runs under port 4040, but where does 11437 come from?)
There isn't even an explanation, why IE doesn't go on using SSE.
I mean, SSE/Forever Frame does work with IIS 7.5, doesn't it?
Thank you in advance!
PS: Before you ask, I am at home and not behind a proxy
The SignalR requests to port 11437 are being made by Visual Studio's new Browser Link feature which can be disabled.
Can you show us your server-side code (particularly anything in OnConnected)? It would also be helpful to see the responses to the SSE and ForeverFrame /connect requests.
Lastly, looking at SignalR's server-side tracing could be helpful.
Well this is a bit late, but I want to resolve this anyway.
The reason was Bitdefender Internet Security 2013.
It buffers requests or something like that, I don't know exactly :X
Anyways, I uninstalled it and that did the trick :D
Related
I inherited a web app that acts as a corporate dashboard. It's an ASP.NET app. .NET version = 4.7.2
It's running on two Windows 2016 Standard servers running IIS 10. Been in operation for many years.
One of the things the app does is make an HTTP request to a particular https:// URL, grab the data, parse out the JSON, and cache the list of objects. This has been working for many, many months. (Note: the "remote" server we're calling is still "in-house". Another person within my team basically "owns" that.)
Well, on Thanksgiving Weekend, it looks like the Prod App Pool cycled. And immediately that query started erroring with "System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel."
Myself and a few other folks were paged. At the time, we didn't notice (in Event Viewer) that the App Pool had cycled. After a few hours of investigating (and rebooting the app servers), the fellow who "owns" the server we are querying quickly set up a new end point for that same resource...setting it to allow HTTP connections / not require the use of HTTPS. The intention was that this would be a work-around until we could investigate the problem later.
Well, it's now "later".
The remote server that we are calling appears to require the use of TLS 1.3. I confirmed this by using both Firefox and Chrome on my own laptop to pull up a couple of https: urls on that server.
So, Ah-ha, I thought to myself, I had found information earlier this afternoon suggesting that Windows Server 2016 Standard didn't support the use of TLS 1.3! (https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-#tls-protocol-version-support)
But then I remembered: Earlier, I had been able to pull up those https: URLs in Chrome while logged onto my app's webservers! Sure enough, I went over there and retested with Firefox and Chrome. Both said the connections they'd made were using TLS version 1.3 !!
So, what the ???? That makes it seem like Windows Server 2016 Standard DOES support TLS 1.3 !??
And, from everything I've read, since my app is using .NET version 4.7.2, it should default to using whatever the default protocol for the OS is. So, shouldn't it too be using TLS 1.3 ? Why the heck can't it make a connection?
I'm certainly needing some direction on what to do next.
Thanks!
Background
Many statements from your question body above are true, but you need to put the contents into contexts so as to get the whole picture.
First, Chrome/Firefox supports TLS 1.3, but that support comes from the crypto libraries (many options out there, Mozilla NSS, OpenSSL and so on) they ship with themselves, not from Windows native crypto API.
Second, like you found out, Windows Server 2016 does not support TLS 1.3 natively because its underlying crypto API lacks of TLS 1.3 support. TLS 1.3 support is only included in Windows Server 2022 at this moment (and whether it will be back ported to previous Windows versions is unknown).
Third, when you try to analyze Windows components (like .NET Framework) or products, you need to identify what they rely on to perform TLS, Windows native crypto API or their own dependencies (like Chrome/Firefox does).
Answer to your specific ASP.NET question
Sadly it is well known that BCL classes in .NET Framework rely on Windows native crypto API, so on Windows Server 2016 you can go with TLS 1.2 at most.
If your application needs TLS 1.3 badly, you need to upgrade to Windows Server 2022, or switch to a third party crypto API.
Reference
https://www.quora.com/How-does-one-decide-between-OpenSSL-GnuTLS-and-Mozillas-NSS
TLS 1.2 on Windows Server 2003 and XP
Background
In a version of Safari that supports HTTP/2 (i.e. v9+) running on macOS “El Capitan” v10.11 or newer, when accessing a webpage served from IIS10 via HTTP/2 (e.g. Windows Server 2016 / Windows 10), if the page contains a "Response.Flush" then it will not load. It simply hangs with a white screen. Web server CPU usage also spikes during these occurrences.
This thread suggests that when Response.Flush is used, IIS switches protocol from HTTP/2 back to HTTP/1.1. Safari cannot handle this, whilst all other browsers seemingly can.
Demos from the link above:
Working - http://limoeventplanner.com/safari-test.asp
Not working - https://limoeventplanner.com/safari-test.asp
I appreciate that the solution to this problem may lie elsewhere (I currently have a bug open with webkit), so I will try to make my questions focused...
TL;DR
Does using Response.Flush still make sense in a HTTP/2 environment?
Is the "downgrade" to HTTP/1.1 by IIS the expected behaviour in this scenario? If so, why?
I'm trying to learn about WebSocket as I see many possibilities with it and would like to explore it, but I am having a hard time understanding the basic requirements for it.
There exist a ton of blogs out there praising WebSocket like was it God and they explain how to develop WebSocket applications brilliantly.
However I don't understand when they all shortly mention that you need a WebSocket compatible server and then none of them tells you how to set it up and what you need to do to make it work properly when you call it through your client side scripts etc. - Even WebSocket.org fails to explain it.
Can anyone point me in the right direction?
Say I have an ASP.NET website and would like to use WebSocket to push notifications, maybe even have a chatroom. What would I need to do to make my Javascript-based chatroom application working?
If you are using ASP.NET, you will need IIS8 to work with WebSockets integrated in the app (so you would need Windows 8 or Windows 2012). Or, you can have a WebSocket server in another port/server.
If your "push" requirements are not very exigent, you can try SignalR: http://www.asp.net/signalr. Check out their tutorials to get started. But again, you won't be able of using WebSockets unless you are using IIS8.
Other WebSocket frameworks are XSocket.NET and SuperWebSocket. Or if you want you can take a look at my WebSocketListener that I am developing, that is just a lightweight WebSocket connector and nothing more, although it is under heavy development at the moment.
From client side, the WebSocket API is the same for all browsers.
Your question is very broad and not any particular problem specific.
WS (WebSockets) is protocol that is implemented in most modern browsers and platforms, and is well consistent.
But same way as you need something to be as HTTP web server (ASP.Net + IIS, Apache + PHP, node.js, python, etc) you need similar or compatible technology for WebSockets. As it is different protocol, your technology have to support. From "recognising" traffic as WS, directing to right process via socket/proxying, handshaking, deserializing traffic into actual data, and providing you an interface to work with all of it.
So you need basically google: "%YOUR TECH/LANGUAGE% WebSockets". That will give you information on how to use WS on your platform.
You need to understand specifics that it is different protocol, so it might not be that "friendly" with some complicated infrastructure cases.
ASP.Net 4.5 do support WebSockets by default, just find documentation on how to use it in ASP.Net.
And this question would not be raised if you would try to do some experimentation and prototyping with WebSockets in first place.
I'm developing an AJAX-heavy site with JavaScript MVC and an ASP.NET MVC server. To test some of the client-side caching and get a better idea of where to put loading gif's and messages into the site I would like to artificially simulate some latency on the server.
I guess the easiest way would be to use a Global Action Filter and simply do a Thread.Sleep, but this won't work for when the client loads JavaScript files and other content.
I'm guessing I can do this with an HttpModule, but I'm note sure.
Any ideas?
Edit: This is for testing on my local/development machine, using IIS Express
Looks like most straightforward solution would be to leverage bandwidth throttling by reconfiguring IIS: Enabling Bandwidth Throttling (IIS 6.0)
Also here is a trick to simulate a modem connection when using a Fiddler using the menu option
Rules > Performance > Simulate Modem speeds
Say a website on my localhost takes about 3 seconds to do each request. This is fine, and as expected (as it is doing some fancy networking behind the scenes).
However, if i open the same url in tabs (in firefox), then reload them all at the same time, it appears to load each page sequentially rather than all at the same time. What is this all about?
Have tried it on windows server 2008 iis and windows 7 iis
It really depends on the web browser you are using and how tab support in it has been programmed.
It is probably using a single thread to load each tab in turn, which would explain your observation.
Edit:
As others have mentioned, it is also a very real possibility the the webserver running on your localhost is single threaded.
If I remember correctly HTTP standard limits the number of concurrent conections to the same host to 2. This is the reason highload websites use CDNs (content delivery networks).
network.http.max-connections 60
network.http.max-connections-per-server 30
The above two values determine how many connections Firefox makes to a server. If threshold is breached, it will pipeline the requests.
Each browser implements it in its own way. The requests are made in such a way to maximize the performance. Moreover, it also depends on the server (localhost which is slower).
Your local web server configuration might have only one thread, so every next request will wait for the previous to finish