Disabling HTTP/2 / SPDY in HTTP.SYS and IIS in Windows 10 - iis

When testing on Windows 10 we were seeing lots of browser incompatibilities that I hadn't seen before with earlier Windows versions. Some browsers would work, but others would report ERR_SPDY_PROTOCOL_ERROR. My quick search for this problem showed I was not alone.
My app uses WWSAPI and HTTP.SYS with HTTPS (TLS). Does anyone know how to disable SPDY / HTTP/2 in WWSAPI (which is using HTTP.SYS) on Windows 10?
I'd also love to get a full up-to-date Windows 10 list of registry settings for HTTP.SYS.
See below for my answer to this. Hope this helps others too.
Mark

EDIT: disabling HTTP/2 will significantly slow down the speed of your website, this is not a permanent solution. The problem turned out to be caused by our webapp sending a wrong authentication header to the server.
To still disable HTTP/2, see below.
(OP gave a helpful answer, but in the question. I moved the answer):
I did work around my HTTP/2 problem by configuring Windows 10 HTTP.SYS
in the registry to disable HTTP/2. Given that I didn't find info
anywhere, I thought I'd share my solution to that problem here too. I
would like to find a way of doing this through WWSAPI though.
If I turned off SPDY support in the client browser, it would work but
I wanted to turn this off at the server side (HTTP.SYS on Windows 10)
so that it wouldn't negotiate HTTP/2 but would use the older more
compatible HTTP(S).
Discovered two new registry settings for HTTP.SYS in:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
EnableHttp2Tls REG_DWORD 0
EnableHttp2Cleartext REG_DWORD 0
Adding these values and setting both to 0 in Windows 10 resulted in
HTTP/2 / SPDY not being negotiated and my ERR_SPDY_PROTOCOL_ERROR
problems went away without requiring browser configuration changes.
I'm not suggesting there is anything wrong with Windows 10 HTTP/2, the
problems may be with certain browsers.
This may work for IIS too, but I don't use that so I haven't tried and
in any case there may be a better way to do this in IIS.
Hope this helps others too.
I can confirm this helps for IIS too, but I had to restart my computer.

Related

Puppetersharp Proxy Issue on IIS

While hosting an application that we use Puppeteersharp on IIS, I get a 407 error. I make the relevant proxy settings, but I still keep getting the same error.
I tried each of the settings in the picture, but the result did not change. I'm sure the username and password are correct.
When I run the application exe, it goes to the internet without being connected to the proxy, but IIS does not come out either.
How do i solve this problem?
I faced the same problem. This is probably caused by the puppeteersharp library that is running under your project. The library may be going to another url to configuration some settings. So the proxy server may be blocking these urls. You can detect this url and allow it. I couldn't solve the problem then i changed my library as selenium. This solve my problem in IIS.

isapi dll force download

I have a legacy ISAPI dll, that generally fulfills requests just fine, but occasionally I will get prompted to save the dll from my browser. This is a known issue, with some good workarounds. IIS 8.5 serving dll for download instead of executing Hitting download will give you a zero byte file.
I am actually interested in doing the opposite of the workaround. How can I force this (incorrect) behavior, ie, is it possible to trick the server to download the full ISAPI dll? If so, what settings should I change. I am running IIS 7.5.
[EDIT] For clarity, I am not trying to hack anything client side. I doubt that's possible, but if it is I would really like to know. I am trying to figure out if it is possible to get the server to give up the dll with just a plain old post/get request. This is how I got it to give me the dll the first time, luckily it was zero bytes.
Thank you

Acumatica:WsdlBuilder.ProcessHelpRequest(context) throws error after installing self-singed certificate

I have two environments. 1 online, the other is local.
online is user trial environment: win server 2016, sql server 2016,
IIS 10.0, authorized organization signed SSL certificate. Acumatica
18.000.0062
Local is development environment: windows 10, sql server 2016, IIS
10.0, Self-signed SSL certificate. Acumatica 18.000.0062
Online environment performs properly consistently, no matter for SOAP
service or Restful service(using oath 2.0).
However, Local worked correctly at the beginning, which means the screen-based API worked properly with the WSDL of each screen's web service be generated correctly at that time, and contract-based API responded correctly using cookies mode. Here comes the problem. After I installed self-signed certificate in order to use oath 2.0, both SOAP and rest APIs are crashed with same error "Object reference not set to an instance of an object".
I have digged by myself, the obvious phenomenon that indicating something went wrong is the "tools--web service" to generate WSDL. Before self-assigned certificate be installed, All screens could be generated correctly, after , all screens encountered the same error
Source File: ...\Frames\WsdlHelp.aspx.cs Line: 9
I don't want to be misleading, but these are the details as much as I could provide. What my point is the online and local environment are almost exactly the same, online always works properly even with SSL on. So my large guess is there is something to do with the self-signed certificate. however, even after turned off the https on local IIS, the problem still exists. SO,
Is there anyone can give me some help on this headache issue?
Unfortunately, this is a known issue with Acumatica and .net 4.7.2. It was fixed in 2017R2 Update 8 and 2018R1 Update 2. I'm afraid you have no choice but to either downgrade .net to 4.7.1 or upgrade Acumatica to one of those versions.

Dreamweaver Database connection to phpmyadmin not working

So, I realise there are a lot of threads with this topic already but I have went through every single one of them (Majority of them are the exact same) and nothing seems to work.
**As a note, I am using a trial version of Dreamweaver cc 2015, and I am using WAMPSever.
So, I have a testing server working. The problem I am having is creating a MySQL connection from Dreamweaver to phpmyadmin. The error that persists is the:
HTTP ERROR CODE 404 File not found. Here are some possible reasons for the problem:
1) There is no testing server running on the server machine.
2) The testing server specified for this site does not map to the. Verify that the URL in the prefix maps to the root of the site.
I have moved the MMHTTPDB.php and mysql.php into the right folder. I have also selected the server model to be PHPMYSQL.
This is my site:
This is the testing server:
I am fairly new to using Dreamweaver but I have not been more frustrated with anything in my entire life.
Any help would be much appreciated.
I was in a similar situation a week ago and spent sleepless nights trying to find a solution. Like you, I have never been frustrated as I was by this. Finally, I had to downgrade my XAMPP version because I learnt that if you're using the deprecated server behaviors in Dreamweaver, they won't work with the latest version of XAMPP.
I downloaded an older version and I am okay now.

.NET 3.5 Service Pack 1 causes 404 pages on ASP.NET Web App

I have a problem with IIS 6.0 ceasing to work for an ASP.NET application after installing Service Pack 1 for .NET 3.5.
I have 2 identical virtual dedicated servers. Installing SP1 on the first had no adverse effect. Installing it on the second caused ASP.NET pages to start returning 404 page not found.
Static .html pages working okay on both servers.
Has anybody else experienced this?
This is broad problem, so let's start by asking some troubleshooting questions:
Based on your description, the ASP.NET runtime is not catching your request and processing the aspx files. You may need to register the asp.net pipeline with IIS again using ASPNET_REGIIS -i.
Have you made sure that the app_offline.htm file has been removed
from the directory of the application?
I have had this happen before after an
update.
Have you setup fiddler for instance to follow the request to see what is
exactly being requested?
Make sure ASP.NET is enabled in the IIS Administration Console under "Web
Service Extensions." Make sure everything is set to allowed for your different versions of the framework.
Well, let's start with those and hopefully we can guide you to the problem.
I've seen various people with this problem recently. This link might help.
And this one.
And a few others.
Is CustomErrors in your web.config set to On or RemoteOnly? If so, what do you get when you change it to Off?
I have not had this exact error with .NET 3.5 SP1, but have seen similar occur in the past. Typically it can be resolved by opening a command prompt, going to the appropriate .NET folder and running ASPNET_REGIIS -i. In the case of .NET 3.5 there wasn't an update to the main bits of the framework, so you'd actually go to the .NET 2.0 folder, which on my machine can be found at:
\Windows\Microsoft.Net\framework\v2.0.50727
Running the ASPNET_REGIIS -i will re-register all the ASP.NET libraries with IIS, and should be the equivalent of a re-install of the framework on a given machine (as far as IIS is concerned)
Just to clarify. The last (4th) point given by Dale was the problem. During the installation of SP1 the Status for ASP.NET and WebDAV became set to Prohibited under Web Service Extensions.
Why the installation of SP1 changed this setting on one server and not the other is a mystery that I wouldn't mind (but not expect) an answer to...
The second link provided by CodingTheWheel also had the answer so I'm also going to mark this as an answer.
No-one did before, so I'll point to the trivial solution:
Have you already de-installed the Service Pack and re-installed it again (or the whole framework)?
Edit: #Kev:
Easy explanation: He said the update works on one machine, but not on the other. I had similar problems in the past and re-installing helped to solve some of them. And it is trivial to do.
That's my approach:
1. trivial
2. easy
3. headache
You are right, on productive systems you must be careful, but that's his decision. And because it is a virtual server, maybe it is easy for him to copy it and try as a test environment first.

Resources