There's been a lot of news lately about the HTTP/2 standard, very similar to Google's SPDY.
It seems like most modern browsers support much of the functionality the finalized HTTP/2 draft lays out (see here, for example).
But, from the viewpoint of server side coding using ASP.NET and IIS, it's difficult to find much information from Microsoft about how this standard will be used in the .NET framework, especially with ASP.NET (see here).
What options are available for incorporating the technologies available through HTTP/2, in a solution currently using .NET framework 4 or above?
Also, has anyone found any news from Microsoft about if the System.Net namespaces and classes will be updated?
Sorry for the basic question formats - I'm new to web development, and just want to make sure I stay on track of new and emerging technologies.
2016-07-21:
HTTP/2 requires Windows 10 or Windows Server 2016 on the server side. Those operating systems ship with IIS 10. So far IIS 10 has not been made available for installation on older operating systems. Given past behavior it is unlikely it ever will become available on downlevel operating systems.
With SSL enabled (which is a requirement of the HTTP/2 protocol), IISExpress on Windows 10 will begin interacting with the browser using the updated protocol.
(https://weblogs.asp.net/scottgu/released-today-visual-studio-2015-asp-net-4-6-asp-net-5-ef-7-previews)
Given that HTTP/2 does not change any of the HTTP semantics I do not expect applications to do anything special to make use of that. It should work with any .NET version and any framework. I have not tried it, though.
February 2015:
For now you need a proxy server in front of IIS. Or a CDN which does HTTP 2. I expect all major ones to very quickly support it given that all browsers already support it.
The Win10 version of IIS will support HTTP 2 according to currently available Microsoft information.
I'm pretty sure the network BCL classes will be updated eventually given how much steam is behind HTTP 2. All clients and servers seem to be willing to support it very quickly.
Related
I have a simple challenge as I'm working on a multi-platform project where I have a server with TLS 1.2 and a client certificate that is required to authenticate any REST API calls. This works fine on Linux, in WSL and in Docker/Linux. But not on Windows!
On Linux systems, .NET Core will use OpenSSL for the security stuff. On Windows, SChannel is used instead. And SChannel has some issues with my certificate and this specific server. Which is annoying as I have no control over the certificate, nor the server. And whomever built the server apparently never tested things properly with Windows and SChannel. (But we have requested that they fix it!) So I'm looking for an alternative...
The alternative is to just use OpenSSL instead of SChannel in Windows. So I went digging into the HttpClient code and all it's complexities with abstract classes, tasks, asynchronous code and many, many delegates and lambda function. And although I'm an expert with C# as I basically used it since 2004 or so, I still can't find a solution to tell HttpClient to explicitly use OpenSSL instead of SChannel.
Something with Ciphersuites that seem to be unused in Windows, bla, bla. It's complex and there definitely seems no simple answer for what I'm looking for. It's even more annoying to search on the Internet for solutions as many results are for .NET 4.8 or older versions, not .NET Core 6. Some 4.7 documentation does mention that the ServicePointManager will use the protocols provided by the host operating system, thus I'll end up with SChannel on Windows. Apparently, that's still true for the latest .NET versions...
[edit]
Internet Explorer might be obsolete, but it shows the problem with SChannel as Chrome, Edge and other browsers use different libraries, not SChannel. And yes, TLS1.2 is used here, and all ciphersuites have been activated on my Windows system, yet it still won't accept it. Tried a lot to get IE to accept the site and none worked. So I want to work around SChannel or else I have to scrap using .NET as development environment for this project.
Not saying it's impossible, but windows SSL functionalities are built entirely around SChannel thus the nightmare you are running into trying to replace it. You may want to look at a different route which is a hack and something that goes against best practices in HTTPS/SSL code....
Being your cert is more or less FUBAR and you don't have control of it. Best practices go out the window...
You could use the certificate validation callback, if your certificate matches the attributes you are interested in, accept it and return true. Just don't auto accept anything as shown in most examples as that's a huge security hole. This should get around whatever SChannel is complaining about and allow you to accept the cert until they fix it.
Just out of curiosity what error is it throwing?
I'm creating an app that is downloading some content from a HTTPS-based website (and POSTs something back). The web server is using forced encryption (TLS 1.2 with modern ciphers), so all browsers before Firefox 30 can't open pages from it. At all.
The app is written in C# using .NET 4.6 HttpWebRequest and all is working okay. But I want to add support for older Windows XP machines that are still alive, where only .NET 4.0 is available. Also it will be prefect if the app will work even in Win2000 with .NET 2.0, but it's more like a inreal dream. :)
Is it possible to add support for HTTPS requests to modern servers in .NET 2.0/4.0 app? May be via OpenSSL, Mozilla NSS or something such...
I'm maintaining an enterprise C# application that provides end-user extensibility through user-defined JavaScript functions (with a select few C# types/proxies exposed) (think financial algorithms).
We evaluate those functions using ClearScript (prevously we were using another library called Noesis however we've moved away from that).
I'd like to offer a way for end-users to perform very basic debugging of the scripts (through a web interface). At a minimum - inspect variables and step over/into functions.
I've successfully connected to the ClearScript engine w/ Chrome when running the app locally and have been able to step through the scripts - however I don't think the same would make sense for end users whilst running in production for various reasons:
Might be too tricky for them to set up
Possible difficulties with port allocation
Probable firewall issues
What I'd really like is a SignalR interface to the V8 debugger - the web-app would interact with the SignalR, and SignalR would interact with the V8 debugger.
Has anyone done something along these lines before?
Are there any relevant .NET libraries I should be looking at?
Am I right in my thoughts that this seems like a fairly big piece of work?
Any other advice?
It's a web-socket based protocol - though you must make a request via HTTP to retrieve the tabId first (request to /json/list)
https://chromedevtools.github.io/devtools-protocol/1-2/Debugger describes the protocol - there are different revisions targetting different versions of Chrome but 1.2 (stable) seems to work w/ the version of ClearScript I used.
As well as request-response (command) type interactions on the websocket, V8 will also publish events - e.g. Debugger.scriptParsed & Debugger.paused on the same socket.
Some of the key commands:
Runtime.enable
Debugger.enable
Runtime.runIfWaitingForDebugger
Debugger.getScriptSource
Debugger.resume
Debugger.evaluateOnCallFrame
Runtime.getProperties
I've written a small demo project https://github.com/flakey-bit/ClearScriptDebugging/ that shows a target process being debugged by another process.
If you mentioned Chrome and Nodejs, You maybe know that Nodejs, Chrome and Edge support WebSocket naturally. Chrome and Edge better with all security options. For Nodejs you can find standard libraries like socket.io
For the server side DotNet WebSocket
WebSocket protocol is linga franka today.
I am looking for an embedded Web Server with out of the box SSL support, preferably configured from a command line or some easy config, without the need to change system wide config (like Registry). It should also work on mono.
Have you tried my old server http://webserver.codeplex.com? It supports SSL and at least used to run on MONO.
I'm also (slowly) building a new one, it got no SSL support yet (but's not that hard to implement by yourself): http://github.com/jgauffin/griffin.webserver
Edit
The HttpListener in Griffin.Framework have SSL support now
I recently came across two such packages.
ceenhttpd - https://github.com/kenkendk/ceenhttpd
and
uHttpSharp - https://github.com/Code-Sharp/uHttpSharp
The part i like about these is that both of them let you load a certificate file from disk. If you use the raw HtttpListener, that is a pain.
If you are open to use .NET Core, you can also self-host Kesterel. I plan to use this as soon as I convert my projects to .NET 5. here is a small sample code for that.
I am trying with setting a web service without using IIS.
I knew we can use HttpListener to create simple http server before. I am wondering if it is deprecated now since WCF seems provide more advanced features.
Take a look at the HttpListener Class documentation:
This class is available only on computers running the Windows XP SP2 or Windows Server 2003 operating systems. If you attempt to create an HttpListener object on a computer that is running an earlier operating system, the constructor throws a PlatformNotSupportedException exception.
So, if you can use it depends on the operating system you want to run your program on.
Microsoft recommend against using it. I'd go with WCF if you need to know it'll be maintainable for some years.
Alternatively, if you're happy to expose RESTful services rather than SOAP or XML-RPC, there are a few standalone .NET assemblies you can use to host an HTTP server in your app without any dependency on IIS or WCF - they'll run under Mono, too, with no problems:
Nancy - http://nancyfx.org/
Kayak - https://github.com/kayak/kayak
Firefly - http://loudej.github.com/firefly/
We use them to make sure we have complete control over the server stack, and can tweak things outside the parameters of the black-boxes that are .NET's HTTP listeners.