HTTPS request hanging after 6 request in a row with WebKit based browsers and IIS

aggutierrez commented 1 year ago

Expected Behavior

I've setup a couple of sample ASP.Net 6 APIs, one of them with Ocelot as the gateway, and tried to route requests to a given endpoint to a donstream API. Debugging with Rider everything works fine, and deployed to IIS works also fine if I configure HTTP bindings, but If I set up HTTPS bindings for both APIs and configure Ocelot routing to use HTTPS protocol, I would expect it to work OK, as through HTTP.

Actual Behavior

If I configure Ocelot to route through HTTPS, every 7th request from a WebKit based browser (I've tested Chrome and Edge in their latest versions) hangs for an undetermined time.

Some things I've tested so far

Starting the gateway API with Kestrel, executing dontent MyProject.dll seems to work fine and I'm unable to reproduce this issue.
Disabling HTTP/2 in both APIs in IIS seems to fix this issue too (although it's not a proper fix).

Steps to Reproduce the Problem

Create a blank ASP.Net 6 Web API project for the downstream API
Create a blank ASP.Net 6 Web API project for the gateway and install Ocelot (I've tested this with versions 18 and 20 with .Net 7)
Configure the gateway to route to the WeatherForecast endpoint of the donwstream API
Deploy both projects to IIS web sites and configure HTTPS bindings for the websites
Open a modern WebKit based browser and navigate to the gateway WeatherForecast endpoint so you get routed to the downstream API.
Browse 7 times to this same endpoint, till it hangs.

Specifications

Version: Ocerlot v18 and v20
Platform: ASP.Net 6 and ASP.Net 7
Subsystem: Windows Server 2022 21H2 + IIS

raman-m commented 1 year ago

Is it a question or real issue, in your opinion, Alejandro?

ggnaegi commented 1 year ago

Hello @aggutierrez, are you experiencing the same issue as others with IIS? https://github.com/ThreeMammals/Ocelot/issues/1630 https://github.com/ThreeMammals/Ocelot/issues/1591 If I have some time, I will try to reproduce the problem you discribed myself.

aggutierrez commented 1 year ago

Hi, @raman-m! It's mainly a question. I'm not sure it has 100% to do with Ocelot but I need to gather some info.

aggutierrez commented 1 year ago

Hi @ggnaegi! It behaves more or less like those issues, but in my case it's always at the 7th attempt. Also, I tried modifying the ocelot.json to redirect to the donwstream API using the IP address, instead of the domain name, as they suggest in one of the issues but that doesn't fix it and I keep reproducing this same behavior.

To be honest, to me it looks like it has to do with how WebKit browsers understand the end of a connection and how IIS implements HTTP/2. It looks like if the browsers never killed the previous threads, waiting for the server to finish the connection, and at some point they reach the maximum number of threads available, so the 7th request has to wait for a thread to be available. If I call the endpoint from Bombardier, for example, I've no issues and I can call any number of times.

raman-m commented 1 year ago

Guys, if you don't mind, I'm moving this thread to Discussions... It is not exact well-formulated question, it is like user scenario, so it'll be a General discussion.

raman-m commented 1 year ago

@aggutierrez I don't recommend to host Ocelot app by IIS. You must tune and provide correct settings for all IIS features, modules, handlers... you know this is a pain in the neck! IIS is a web server for classic web apps with ASP.NET front-ends. For ASP.NET Web API apps without front-ends it is better to use lite web servers like Kestrel. Using self-hosted, Kestrel, Docker deployments are better.

I have no idea how to provide correct IIS settings for HTTP/2 protocol, but technically Ocelot should support HTTP2. You have to read tons of articles on how to setup IIS for HTTP/2.

ThreeMammals / Ocelot