-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
Comments
cc @stephentoub, 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. |
Could it be maybe something to do with the |
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. |
@blogcraft can you verify the HTTP version you are using? Is it HTTP/2 or HTTP/1.1 |
@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? |
@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? |
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! |
Please don't close this. |
@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.
I see a bunch of Other requests come back normally: But the cancellations seem to loop and don't send an actual cancellation/failure upstream. It seems from the network trace that the request is pending: One way to go about this, is to add a timeout on the proxy code in your proxy.conf.js for example You can check how to fine-tune this on https://github.com/chimurai/http-proxy-middleware#readme |
@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. |
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. |
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. |
@davidfowl I think setting the proxyTimeout on our templates is a good solution while we determine what is going on. |
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 When we click on the Cancel Request Button , that call never hit the below breakpoint. |
@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 |
@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. |
@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. |
|
This issue seems to be related to nodejs/node#46666 |
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
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
The text was updated successfully, but these errors were encountered: