5

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.

mikeo
  • 1,045
  • 13
  • 17
  • 1
    Can you share the program and startup classes so that we can determine whether everything is correct in your code? – Camilo Terevinto May 01 '18 at 01:00
  • Can't share the program (it's huge) but this can be easily repro-ed using the default ASP.NET Core Template. Run it under IIS Express and cancel loading the page, RequestAborted = False. Run it under Kestrel, RequestAborted = True. I'll see about putting a repo up for it. – mikeo May 01 '18 at 01:07
  • Is it possible that the aborts are undetectable? After all, if the client is pipelining (http1.1 reuse of the same underlying connection), then an aborted request is not necessarily an aborted connection. IMO there's a larger problem that might be addressed in another place if such a large number of users are bailing on the request/response. – spender May 01 '18 at 01:07
  • It's a proxy against a mapping server which bails on requests after zoom/pan. Which can result in a huge number of canceled requests depending on how long it takes the server to render. I also (partially) understand the larger HTTP Protocol issue...but the fact of the matter is; it works as intended when using Kestrel alone...not when IIS is in front of it. – mikeo May 01 '18 at 01:09
  • A comparison of request/response headers from the two different scenarios *might* yield something. I'd be interested in the `Connection` headers. – spender May 01 '18 at 01:16
  • [This comment](https://github.com/aspnet/KestrelHttpServer/issues/1139#issuecomment-258281409) makes me think like this won’t work with IIS. – poke May 01 '18 at 01:43
  • Yes, I saw that too but was not exactly sure what it was in reference to and/or if it means I'm doa on this. – mikeo May 01 '18 at 02:17

1 Answers1

3

This is known issue and isn't fixed yet. See https://github.com/aspnet/AspNetCoreModule/issues/38

KennyT
  • 56
  • 7