Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
aggutierrez opened this issue Oct 13, 2023 · 6 comments
Assignees
Labels
question Initially seen a question could become a new feature or bug or closed ;)

Comments

@aggutierrez
Copy link

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

  1. Create a blank ASP.Net 6 Web API project for the downstream API
  2. 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)
  3. Configure the gateway to route to the WeatherForecast endpoint of the donwstream API
  4. Deploy both projects to IIS web sites and configure HTTPS bindings for the websites
  5. Open a modern WebKit based browser and navigate to the gateway WeatherForecast endpoint so you get routed to the downstream API.
  6. 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 raman-m added the question Initially seen a question could become a new feature or bug or closed ;) label Oct 13, 2023
@raman-m
Copy link
Member

raman-m commented Oct 13, 2023

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

@ggnaegi
Copy link
Member

ggnaegi commented Oct 13, 2023

Hello @aggutierrez, are you experiencing the same issue as others with IIS?
#1630
#1591
If I have some time, I will try to reproduce the problem you discribed myself.

@aggutierrez
Copy link
Author

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
Copy link
Author

aggutierrez commented Oct 16, 2023

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
Copy link
Member

raman-m commented Oct 18, 2023

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
Copy link
Member

raman-m commented Oct 18, 2023

@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 ThreeMammals locked and limited conversation to collaborators Oct 18, 2023
@raman-m raman-m converted this issue into discussion #1743 Oct 18, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
question Initially seen a question could become a new feature or bug or closed ;)
Projects
None yet
Development

No branches or pull requests

3 participants