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.