Q. Why doesn't IIS/ASP.NET remove waiting requests for disconnected clients?

[Peperud]

This is a fairly common scenario - a page that takes a bit to return (might be a temporary issue), impatient end user keeps clicking, refreshing, closing and reopening the browser etc. Easier to make happen when the application uses session state. So now there are a lot of disconnected requests that IIS/ASP.NET keep pushing through the pipeline.

I understand that if a requests is currently executing when the client disconnects, it will keep going until it fails to write to the response.

However, why wouldn't IIS/ASP.NET check and abort the requests when moving them out of the queue and/or between pipeline stages?

Yes, I know, there is IsClientConnected. Using it before and during resource intensive work is fine and makes sense.
But why is IIS/ASP.NET passing disconnected requests to begin with? To support "fire and forget"? Doesn't seem right. Even if that is the case, there should be a configuration setting for it.

It seems to me that if the very first thing I have to do, each and every time, when I get a request
is to check whether the client is still connected, it sure feels like something that should've been handled at framework level.

[mkArtakMSFT]

Hi. Thanks for contacting us.
We're closing this issue as there was not much community interest in this ask for quite a while now.