Skip to content

HttpContext RequestAborted no longer works. #38917

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

Open
blogcraft opened this issue Dec 9, 2021 · 22 comments
Open

HttpContext RequestAborted no longer works. #38917

blogcraft opened this issue Dec 9, 2021 · 22 comments
Labels
area-ui-rendering Includes: MVC Views/Pages, Razor Views/Pages bug This issue describes a behavior which is not expected - a bug. feature-spa good first issue Good for newcomers. help candidate Indicates that the issues may be a good fit for community to help with. Requires work from eng. team
Milestone

Comments

@blogcraft
Copy link

Describe the bug

Since .NET 6, the HttpContext.RequestAborted does not updates when the request is cancelled. This used to work with .NET 5.
IsCancellationRequested stays in false even tho the request has been canceled and CanBeCancelled is set to true.

To Reproduce

I started a .NET 6 Angular project and created an HTTP GET request and subscribe to it, the Request is in an infinite loop intentionally so it can only be ended by the cancellation token. Also have a subject to cancel the request with an other button.

In .NET 5 this works flawlessly. In .NET 6 its unusable.

An Example Repo can be found here: https://github.com/blogcraft/TestCancel

Exceptions (if any)

Further technical details

  • ASP.NET Core version: .NET 6.0.100
  • The IDE (VS / VS Code/ VS4Mac) you're running on, and its version: VS Code
  • Include the output of dotnet --info:
SDK de .NET (que refleje cualquier global.json): Version: 6.0.100 Commit: 9e8b04bbff

Entorno de tiempo de ejecución:
OS Name: Windows
OS Version: 10.0.22000
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\6.0.100\

Host (useful for support):
Version: 6.0.0
Commit: 4822e3c3aa

.NET SDKs installed:
3.1.415 [C:\Program Files\dotnet\sdk]
5.0.401 [C:\Program Files\dotnet\sdk]
6.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 3.1.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.21 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.21 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download

@davidfowl
Copy link
Member

cc @stephentoub, just in case there's any insight here.

@stephentoub
Copy link
Member

just in case there's any insight here.

Haven't tried the repro, but if token.CanBeCanceled is true and token.IsCancellationRequested is false, it simply sounds like no one is canceling the CancellationTokenSource.

@martincostello
Copy link
Member

Could it be maybe something to do with the CancellationTokenSource pooling/re-use that was added in 6.0?

@davidfowl
Copy link
Member

Could it be maybe something to do with the CancellationTokenSource pooling/re-use that was added in 6.0?

Yes it could be. The change was very small but I haven't spent any time investigating it to see if there's a bug somewhere.

@davidfowl
Copy link
Member

@blogcraft can you verify the HTTP version you are using? Is it HTTP/2 or HTTP/1.1

@blogcraft
Copy link
Author

@davidfowl Can You help me with that? My development environment I use the project as is (just the same as I used with .NET 5). Is there a way to force HTTP/2?
In my production environment I use an Azure AppService that has always been configured tu use HTTP 2.0.

@Tratcher
Copy link
Member

Tratcher commented Dec 13, 2021

@javiercn I think this is because of the new SPA proxy in 6.0, the cancellation doesn't flow through to the server. Can you take a look?

@Tratcher Tratcher assigned javiercn and unassigned Tratcher Dec 13, 2021
@Tratcher Tratcher added area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates feature-spa and removed feature-kestrel area-runtime labels Dec 13, 2021
@TanayParikh TanayParikh added this to the Discussions milestone Dec 14, 2021
@ghost
Copy link

ghost commented Feb 12, 2022

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!

@ghost ghost closed this as completed Feb 12, 2022
@blogcraft
Copy link
Author

Please don't close this.

@stephentoub stephentoub reopened this Feb 12, 2022
@Tratcher Tratcher removed this from the Discussions milestone Feb 14, 2022
@javiercn
Copy link
Member

@Tratcher from what I can tell, the "cancellation" is not even making it back to the proxy.

I added some logs to the proxy code to validate this.

const PROXY_CONFIG = [
  {
    context: [
      "/weatherforecast",
   ],
    target: target,
    secure: false,
    onProxyRes: (proxyRes, req, res) => {
      console.log(res.statusCode);
      console.log(proxyRes.statusCode);
    },
  }
]

I see a bunch of ok... repeated in the console, so it seems something is stuck in a loop.

Other requests come back normally:
image

But the cancellations seem to loop and don't send an actual cancellation/failure upstream.
image

It seems from the network trace that the request is pending:
image

One way to go about this, is to add a timeout on the proxy code in your proxy.conf.js for example proxyTimeout: 3000,.
That should make sure that the proxy sends back a response instead of holding indefinitely when it doesn't receive a response from the server.

You can check how to fine-tune this on https://github.com/chimurai/http-proxy-middleware#readme

@javiercn javiercn added area-runtime and removed area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates feature-spa labels Feb 15, 2022
@adityamandaleeka
Copy link
Member

@javiercn Can you please share more about what the problem is here? It sounds like a SPA proxy issue, but I see you've moved it to runtime so I want to check what we need to do.

@javiercn
Copy link
Member

javiercn commented Feb 16, 2022 via email

@Tratcher
Copy link
Member

When kestrel aborts the request is it supposed to notify the upstream connection/server in any way?

Upstream server? You mean like client -> kestrel -> reverse proxy -> upstream? In that case Kestrel's RequestAborted CancellationToken is the signal through the app.

If you meant client -> upstream -> reverse proxy -> Kestrel, then a request abort is signaled by closing the associated TCP connection or HTTP/2 stream.

@davidfowl
Copy link
Member

We need look at the logic here https://github.com/http-party/node-http-proxy and see if there's an issue on their end with propagating client disconnection maybe.

@adityamandaleeka adityamandaleeka added area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates feature-spa and removed area-runtime labels Feb 28, 2022
@javiercn
Copy link
Member

javiercn commented Mar 1, 2022

@davidfowl I think setting the proxyTimeout on our templates is a good solution while we determine what is going on.

@javiercn javiercn added this to the Backlog milestone Mar 1, 2022
@ghost
Copy link

ghost commented Mar 1, 2022

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

@javiercn javiercn added good first issue Good for newcomers. help wanted Up for grabs. We would accept a PR to help resolve this issue labels Mar 1, 2022
@singh733
Copy link
Contributor

@javiercn When we click on the Cancel Request Button , that call never hit the below breakpoint.
If this is the First method which accepts the request then cancel request never to the asp.net core.
Please let me know is this the first method which accepts the Request?

image

@javiercn
Copy link
Member

@singh733 not sure what you are talking about. If you are facing a problem, please file a separate issue and provide the required context there. If your problem is similar to the one described here, you can try using the solution we suggested, which is to add proxyTimeout to the proxy configuration.

@singh733
Copy link
Contributor

singh733 commented May 13, 2022

@javiercn I was trying to resolve the above issue. I don't think it is asp.net core problem because the cancel button calls does not hit the EXECUTE method of HTTP2STREAM. It was labelled as GoodFirstIssue that's why i pick this.

@davidfowl
Copy link
Member

@singh733 you're looking at the wrong method, that's not how this works. I think you're a bit in the weeds here. My guess is that the nodejs proxy (the client) isn't disconnecting properly and that's likely why the client isn't seeing the disconnect.

@Lonli-Lokli
Copy link

  • HTTP/2 uses RST_STREAM frame on cancel
  • HTTP/3 uses QUIK RESET_STREAM frame

@adityamandaleeka adityamandaleeka added area-ui-rendering Includes: MVC Views/Pages, Razor Views/Pages and removed area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates labels Aug 25, 2023
@veantm
Copy link

veantm commented Oct 19, 2023

This issue seems to be related to nodejs/node#46666

@mkArtakMSFT mkArtakMSFT added help candidate Indicates that the issues may be a good fit for community to help with. Requires work from eng. team and removed help wanted Up for grabs. We would accept a PR to help resolve this issue labels Oct 28, 2023
@mkArtakMSFT mkArtakMSFT added the bug This issue describes a behavior which is not expected - a bug. label Oct 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-ui-rendering Includes: MVC Views/Pages, Razor Views/Pages bug This issue describes a behavior which is not expected - a bug. feature-spa good first issue Good for newcomers. help candidate Indicates that the issues may be a good fit for community to help with. Requires work from eng. team
Projects
None yet
Development

No branches or pull requests