We have an ASP.NET Core 2.x Application that implements custom middleware that acts as a proxy in front of another (Java based) server/application. It is common for the clients of this application/middleware to frequently abort/cancel their request before the server request has completed.
We've deployed this application to IIS (as a reverse proxy) and running on Kestrel. Prior to Core 2.x Kestrel had a bug that caused HttpContext.RequestAborted to always be false (other related question here)...which was apparently fixed in 2.x (which I've been able to confirm).
However, it appears that when running IIS in front of Kestrel, it doesn't forward the request abort through to Kestrel and RequestAborted is still always false
Is there any way to get RequestAborted working in this configuration (or any other way to detect it if not)?
Simple reproduction repo: https://github.com/mikeomeara1/RequestAbortRepro
UPDATE
This Comment seems to indicate a known issue but it's largely unclear to what extent
This Question seems to also be related but again it's not completely apparent to me that it's directly related (at least it isn't spelled out in such terms).
@spender - If I understood you correctly, the header comparison is here. If not, let me know, I'll get you whatever you want to see.
It seems the tea leaves are indicating a known issue. So, the question is; Is there a way to work around this? We just went through (a very painful) 1.1 to 2.x upgrade in the hopes this issue would be addressed and letting our server thrash for another month/quarter/year has us pretty concerned at this point. The system we're working on is greatly scaling up in volume.
So, any workarounds, hacks or crazy ideas are welcome.
This is known issue and isn't fixed yet. See https://github.com/aspnet/AspNetCoreModule/issues/38
来源：https://stackoverflow.com/questions/50110101/kestrel-iis-reverse-proxy-requestaborted-not-triggered