The new HTTP/3 protocol is supposed to be faster and more secure than HTTP/2. How do I enable it on Windows Server running IIS websites?
As of this writing, HTTP/3 is only supported on Windows Server 2022. If you are on any previous version, I'm afraid you are out of luck.
Assuming you are on Windows Server 2022, here is how you enable it.
Step 1: Update the Windows Registry
Copy and paste the following text into a new .reg file. You can call it something like "enable-http-3.reg"
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters]
"EnableHttp3"=dword:00000001
"EnableAltSvc"=dword:00000001
Once saved, execute it on your Windows Server 2022 by double-clicking it, or by using reg.exe.
Step 2: Enable TLS Cipher
Note: Based on feedback from other users, this step may be optional. However, I needed to enable it on my installation.
Open PowerShell as Administrator to enable the TLS_CHACHA20_POLY1305_SHA256 cipher suite. Execute the following command in PowerShell:
Enable-TlsCipherSuite -Name TLS_CHACHA20_POLY1305_SHA256 -Position 0
Step 3: Allow UDP Connections on Port 443
HTTP/3 uses QUIC protocol which uses incoming UDP connections on port 443. You'll need to allow connections if you're using a firewall. Here is how the rule might look in Windows Firewall:
Step 4: Add HTTP/3 Response Headers to IIS
HTTP/3 requires some special response headers within IIS. Select either the website, or the machine within IIS and select "HTTP Response Headers."
Create a new response header with the name alt-svc and the value h3=":443"; ma=86400; persist=1.
That's it! Now test to make sure HTTP/3 is working in your browser. Many modern browsers li support HTTP/3 so you shouldn't need any configuration changes. However, one thing to note is that HTTP/3 only works on HTTPS connections, so if you're loading a website using HTTP, it will not work. Make sure to configure websites in IIS to use HTTPS protocol.
You will know when HTTP/3 is working via the browser's dev tools. Open developer tools, click on the network tab and note the protocol column. Chrome 108.0.5359.94 screenshot:
Firefox 107.0.1 screenshot:
Troubleshooting Tips
Reboot Windows 2022 server
Make sure the website is loaded via HTTPS! Do you see the lock icon in the browser?
Completely close the browser (all tabs) and restart it before loading the website
Disable the browser cache via browser developer tools when testing
Completely clear the browser cache and reboot the client machine(s).
More resources and references:
https://4sysops.com/archives/increase-iis-performance-with-http3-in-windows-server-2022/
https://blog.workinghardinit.work/2021/10/11/iis-and-http-3-quic-tls-1-3-in-windows-server-2022/
https://techcommunity.microsoft.com/t5/networking-blog/enabling-http-3-support-on-windows-server-2022/ba-p/2676880
Related
I have a new installation of Centos 7 running cPanel and WHM on an AWS EC2 instance. All software is the latest versions.
I used WHM to setup 5 users, which in turn creates linux users with their own home directory and their own public_html directories. Then I have enabled MATE Desktop and Tigervnc so each developer can connect to the machine in a vnc session.
So basically this setup is 5 linux users with their own apache vhosts, running their IDE on the same local server.
I then installed Xdebug using pecl and now I want to setup VSCode on each persons account to use Xdebug. I am also using opcache.
When trying to use VSCode, it seems like we can get the debugger to work, but there is no output in the console of VSCode. I installed the php-debugger extension in VSCode.
Also we seem to have a problem with VSCode not able to handle include/require statements. It always says that they cannot be found. But the files are indeed there and indeed have the correct permissions to be read/written.
I am not really sure how to configure Xdebug and VSCode to get them to work for all local developers with VSCode. Will what I am doing even work? Do I need remote connections? Do I need a DBGp proxy? Does Xdebug only allow one debugging session at a time? Do I need to install Xdebug for each user?
Can anyone provide some directions on how to set this up?
Thanks
Will what I am doing even work?
Likely :-)
Do I need remote connections?
On the Xdebug side, it does not matter whether it's "remote" or on the same machine, in both cases a TCP/IP connection is used. The "remote" in "remote debugger" was always a bad choice of words by the Xdebug developer (me).
Do I need a DBGp proxy?
You don't need it. What you need to be able to do is to have each user initiate a debugging session to their own IDE. As everything runs on the same machine, you can't just reuse ports. Xdebug always connects to the same configured port (9003 by default).
There are two alternatives:
Use a the DBGp proxy to direct incoming connections from the Xdebug port to registered IDEs. Each of these IDEs will have registered their key with the proxy, so the proxy knows where to forward the request to. You will need to use a browser extension so that each developer can set their own unique IDE key as the Xdebug session (cookie) value.
Use Xdebug Cloud, which would handle the complicated proxy set-up for you, and the developers only have to set their IDE Key (or now, Cloud key) through the browser extension again, as well as in their IDE. Only PhpStorm supports this for now. There is configuration documentation available.
Does Xdebug only allow one debugging session at a time?
No. Xdebug supports one debugging connection per PHP request, but IDEs might not accept more than one incoming connection. Both PhpStorm and VS Code's Debug Plugin don't have this problem.
Do I need to install Xdebug for each user?
No. Xdebug is installed as part of PHP, and as you've only got one PHP installation, having Xdebug available as part of the is enough.
Visual Studio 2015 (Loaded as Admin), Web API 2, Windows 10.
I have Local IIS with a subdomain sub.mylocalsite.com mapped through the hosts file to 127.0.0.1. The Web API 2 is loading and I am able to debug and do all the activities as expected.
On IIS, if I add a secure binding, with the proper self-signed certificate (without disabling the non-secure binding, i.e. keeping two bindings) and do an IIS Reset, I am able to access the https Web APIs as expected, however, when I click run to start debugging I get the standard error from VS of Unable to Start Debugging.
Please note that I tried both setting the start URL as http://sub.mylocalsite.com and https://sub.mylocalsite.com to no avail
Any solution?
I experienced the same thing, then saw this blog post. Try attaching to worker process, per this blog post:
https://blogs.msdn.microsoft.com/vijaysk/2007/10/17/visual-studio-debugging-websites-that-require-client-certificates/
The most important requirement for the pretty F5 key to work in Visual Studio is NTLM/Windows Intergated Authentication. Only then can it auto-attach to the IIS worker process. And this is where our trouble starts. Client certificates is a kind of an authentication mechanism. When you configure a website to require client certificates you are changing the authentication mechanism.
So if you are developing a website off an IIS server and you need to debug it with client certificates then you cannot just open your web project in visual studio and start debugging it. But what you can do is attach to the process running your code manually.
Open your project in Visual Studio and set a breakpoint as you usually do
Debug menu > Attach to Process > Select the process running your code.
I'm using VS2015 Update 1 to try and debug my site which I've uploaded in Debug mode to an Azure web app (NOT a vm). I am working from my work domain.
I've been following instructions similar to found here https://samlman.wordpress.com/2015/02/27/another-cool-way-to-remotely-debug-azure-web-sites/
I have:
Published my website in Debug configuration
Enabled Remote Debugging from the management console
Made sure my VS edition is set to 2015
Enabled Websockets (from trying to connect via websockets)
Checked that the firewall allows VS remote debugger, remote debugger monitor and remote debugger discovery through.
Checked the website is up and running (set it to always on just in case)
I have tried right clicking my app service in Server Explorer and "Attach Debugger".
I then tried to connect using Debug > Attach to process and using the qualifier mysite.azurewebsites.net as instructed on various blogs. Even tried transport as Websocket, Remote as well as Default.
All methods get me the following:
I then used Fiddler to see if I could find the answer from web traffic but no joy with that.
Would appreciate any suggestions to get me around this problem!
Edit
Under scm -
There was another firewall I wasn't aware of on the domain that was blocking the debugger.
Edit:
Ports requested
outbound:
UDP 3702
TCP 4020
TCP 4021
Port assignments are given here on MSDN page
Up until recently, everything worked just fine.
However, now, I can no longer connect to Team Foundation Service unless the Fiddler is opened?!
A couple days ago, I've setup the Fiddler according to the configuration tips DecryptHttpS and tip2 and the issues began to occur.
This is the message I get when I try to connect.
I've tried
turning off decrypt https
removing all Fiddler certificates
uninstalling Fiddler
removing all cookies from IE
...
and many other things that crossed my mind, but with no success.
Seems like VS just can't get to TFS without it.
Meanwhile, I can view the TFS perfectly from browser. (And yes, opening a new instance of VS from home page of TFS doesn't work either)
Any suggestions?
Finally managed to get to the bottom of this.
The issue was caused by the following entry in the machine.config in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config and C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config
<system.net>
<defaultProxy enabled = "true" useDefaultCredentials = "true">
<proxy autoDetect="False" bypassonlocal="False" proxyaddress="http://127.0.0.1:8888" usesystemdefault="False" />
</defaultProxy>
</system.net>
Once I got rid of it, everything started working again.
Typically, this would indicate that the client is configured to use a proxy at 127.0.0.1:8888 even when Fiddler isn't running. Typically, .NET clients get their proxy settings from the system whenever they start.
Without Fiddler running, what are your proxy settings inside IE's Tools > Internet Options > Connections > LAN Settings?
If you start Fiddler, then untick File > Capture Traffic, then start your TFS client, do you see Fiddler capturing the client's requests even though capture is disabled?
VS 2012 does not make this easy. Try the following.
1. Shut down VS
2. Open IE
3. Clear your cache
4. Shut down IE
5. Open VS
In VS 2013, you would need to remove the URL from the connection dialog and re-add it.
I applied a self-signed SSL certificate in IIS manager to Default Web Site(added the HTTPS binding) and after that when I'm trying to start the web site, I'm getting the following error message:
"The process cannot access the file because it's being used by another process. (Exception from HRESULT: 0x80070020) ". But when I remove the HTTPS binding, everything works fine.
So, what is the problem? What might have I done wrong?"
Have you tried the Microsoft Support Article that mentions this process error occuring when you try to start a Web site in the Internet Information Services MMC snap-in
If you're trying to do this on a local machine, Skype can block the https port (443). To stop this:
Skype - Tools > Options > Advanced > Connection, then uncheck 'Use port 80 and 443 as alternatives for incoming connections'. Then quite Skype (right click in task bar, 'Quit Skype'), and try starting the website again in IIS.
VmWare Workstation 8 grabs 443 for its VM Sharing feature. You can disable it in the settings. http://communities.vmware.com/thread/341114
Yes exiting the Skype desktop app fixed this for me also.
If your running Windows 8(.1) the Skype App (Windows Store App) doesn't use the local 443 port if you can live without installing the desktop Skype app. Also you can pin it to your taskbar. This solution is good enough for me since I don't need all of the features the desktop version offers.
You may want to use some sysinternals tools to see if the file is really used by another process. I recommend Process Explorer. Once you've located the culprit, you can usually see why it opens the file.
If you can't find any process, maybe your code tries to open the file; check for any file handlers you may not have closed.