Treat client FIN as request aborted

[cesarblum]

For context, see aspnet/KestrelHttpServer#1139

Once the change is made for the issue above, ANCM needs to be updated so Kestrel will have the same behavior when running behind IIS. Right now client FINs are not forwarded to Kestrel by ANCM.

cc @Tratcher

[Tratcher]

WebListener and ASP.NET 4 use HttpWaitForDisconnectEx for this: https://msdn.microsoft.com/en-us/library/windows/desktop/mt786505(v=vs.85).aspx

[davidfowl]

@pan-wang @shirhatti This needs to be fixed for SignalR to function properly and other scenarios...

[KeesCBakker]

Any action on this front?

[MrMint]

This is preventing us from cleanly cancelling long running requests when the client aborts.

[muratg]

Per triage: We'll need to schedule a meeting to decide the behavior we want for 2.1 timeline.

cc @davidfowl @anurse @Tratcher @pan-wang

[flavio1110]

Any news on it? Will this be fixed in 2.1?

[muratg]

Removing from preview2 (this repo is not used anyway)

[davidfowl]

@shirhatti @pan-wang @jkotalik we need this in ANCM. What's the cost here?

[mikeomeara1]

My understanding (and please correct me if I'm wrong) is that this issue is keeping applications that use IIS as a reverse proxy from being able to properly cancel requests even though this issue was fixed in Kestrel 2.x (issue here).

With that presumption in mind:

1. This doesn't look like it make it into the 2.1 previews...correct?
2. If not, is there any update on when this is to be fixed?
3. Is there anything that can be done to work around this fact without abandoning IIS wholesale (e.g. move to WebListener) while it's being worked?

I have an SO question open as well: https://stackoverflow.com/questions/50110101/kestrel-iis-reverse-proxy-requestaborted-not-triggered

Any input you have would be greatly appreciated.

[SamvelS]

Issue is there for 2.1 release version as well.
One more SO question : https://stackoverflow.com/questions/50702303/cant-cancel-task-in-asp-net-core-action

[ti82]

Supposing this gets fixed in an upcoming release, because it is in the ANCM, will sites that use the RequestAborted token hosted in an Azure App Service automatically start working after IIS is updated?

[nenadvicentic]

Will this issue be fixed for final 2.2 release?

[JesperTreetop]

One more vote in favor of fixing this. There's no point in having RequestAborted if it's not dependable, and this affects both "hitting F5 in Visual Studio [IIS Express]" as well as "hosting the app where Microsoft would rather I host it [Azure App Service]".

[Danielku15]

Another vote from my side. I was really surprised that such an essential behavior is not working. The whole cancellation chain within an application becomes irrelevant without somebody initiating a cancel. IIS+Kestrel is supposed to be the recommended setup for productive environments as direct IIS hosting is not officially supported out of the box (only via Owin hacks). HttpSys is okay, it is anyhow the core of IIS, but the raw usage is lacking of various features, I'm doubting that this should be the way to go nowadays, especially if you plan to target non Windows platforms too. Maybe it only my special application setup I am having that I do not have any cancellation at all, but I see this really as a critical issue not getting notified on a client request abort. If you have load intense operations on the backend (e.g. heavy SQL queries, file-IO etc.) those actions will continue to run even though it is not relevant for the client anymore.

I think anyhow that this repository is dead and issues in here do not get the necessary attention from the team as it should. In the main repository you would not get changed like that without feedback. If @muratg and @shirhatti agree, I would recommend to close the issue here and move it to aspnet/AspNetCore. If there is no response in a while, I will simply give it a shot and see what the guys at the main repo say.

[ti82]

IIS+Kestrel is supposed to be the recommended setup for productive environments as direct IIS hosting is not officially supported out of the box

As of .NET Core 2.2 this is not true. Here's a link

[Danielku15]

@ti82 You are right, looks like my statement was based on outdated information. Sorry about that. I striked-out this statement in my previous post. Nevertheless I think it does not change the problem that the ANCM does not report a aborted/closed connection further. I am working on a fresh ASP.net core 2.2 project with the AspNetCoreHostingModel set to InProcess and was suffering of this issue. Thats why I ultimately arrived here after reading tons of StackOverflow posts.