We are currently maintaining a homegrown python "web server" where generating the response for some requests can take a very long time mostly due to heavy computations - these requests are basically posts with very long timeouts (think minutes to tens of minutes).
One problem of this architecture is that there is sometimes the need to cancel such a request - e.g. the user noticed a mistake while configuring the request. Currently, the cancellation is another request, which cancels the long running request - but there are lots of gaps, e. g. what happens if the client simply closes the website?
Currently, we are planning to retire the homegrown abomination of a web-server and switch to something sensible - e. g. Flask running inside of an IIS using wfastcgi. Due to political reasons, IIS is set, so switching to something like gunicorn is out of the window.
All development has stalled on that because nobody has an idea, how to kill the processes run by (w) fastcgi - that concern is simply not part of the fastcgi spec.
My feeling is, that an attempt to build something that incorporates that is a mistake - I would prefer a solution where the server simply offloads such computation intensive tasks to some background server (flask + celery?) and the front-end polls for that.
Unfortunately, the old solution was in place for so long that some devs want to retain the behavior at all costs.
Being not a web server guy I would like some tips / patterns what sensible solutions for such a problem could look like.