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

Treat client FIN as request aborted #38

Open
cesarbs opened this Issue Nov 7, 2016 · 11 comments

Comments

Projects
None yet
@cesarbs

cesarbs commented Nov 7, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Tratcher

Tratcher Nov 8, 2016

Member

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

Member

Tratcher commented Nov 8, 2016

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

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Aug 20, 2017

Member

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

Member

davidfowl commented Aug 20, 2017

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

@KeesCBakker

This comment has been minimized.

Show comment
Hide comment
@KeesCBakker

KeesCBakker Nov 7, 2017

Any action on this front?

KeesCBakker commented Nov 7, 2017

Any action on this front?

@MrMint

This comment has been minimized.

Show comment
Hide comment
@MrMint

MrMint Nov 10, 2017

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

MrMint commented Nov 10, 2017

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

@muratg muratg added this to the 2.1.0 milestone Dec 20, 2017

@muratg

This comment has been minimized.

Show comment
Hide comment
@muratg

muratg Dec 20, 2017

Member

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

Member

muratg commented Dec 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@flavio1110

flavio1110 Feb 12, 2018

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

flavio1110 commented Feb 12, 2018

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

@muratg muratg removed this from the 2.1.0-preview2 milestone Mar 5, 2018

@muratg

This comment has been minimized.

Show comment
Hide comment
@muratg

muratg Mar 5, 2018

Member

Removing from preview2 (this repo is not used anyway)

Member

muratg commented Mar 5, 2018

Removing from preview2 (this repo is not used anyway)

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Mar 6, 2018

Member

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

Member

davidfowl commented Mar 6, 2018

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

@mikeomeara1

This comment has been minimized.

Show comment
Hide comment
@mikeomeara1

mikeomeara1 May 1, 2018

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.

mikeomeara1 commented May 1, 2018

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

This comment has been minimized.

Show comment
Hide comment
@SamvelS

SamvelS Jun 5, 2018

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

SamvelS commented Jun 5, 2018

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

This comment has been minimized.

Show comment
Hide comment
@ti82

ti82 Aug 24, 2018

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?

ti82 commented Aug 24, 2018

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment