I'm reviving this from this thread:
https://forums.iis.net/t/1228655.aspx?No+way+to+end+connection+with+User
Original message:
Please, get in touch with the MS-PHP Core contributors and implement something similar to this:
http://php.net/manual/es/function.fastcgi-finish-request.php
Most modern frameworks rely on registering shutdown functions or similar, and IIS/FastCGI/PHP will keep the connection open (and not deliver the response until then) making them run like a snail.
The only way that FastCGI will actually end connection with the user is to send the Content-Length header, followed by content of such length. That is a nasty workaround that all these CMS do not implement, and that is not feasible to implement with modern web rendering strategies such as Big Pipe where you start streaming to the client the content of the page without knowing how much content are you actually going to send.
And response from MS:
Hi,
I think there is no need to end connection with user. For performance, we can set MaxInstancesand PHP_FCGI_MAX_REQUESTS and so on. For more information, please refer to the document:
https://www.iis.net/configreference/system.webserver/fastcgi
https://mplnsr.wordpress.com/articles/cgi-isapi-and-fastcgi/
I understand that whoever answered did not take the time to properly read and try to understand the issue. This is not a random post. I'm maintainer for several Drupal/Windows integrations and already are in touch with other MS teams trying to fix issues everywhere else.
Let me explain this with more detail:
1. PHP has a stateless architecture. As such, it is very common practice - more now than ever with frameworks such as symfony - to run shutdown tasks once the response has been sent to the user.
2. Currently, the only way to deal with such a situation is to set the Content-Length HTTP header, and once IIS receives that exact number of bytes from the fastcgi process it will end the connection with the user. So from PHP you flush() enough bytes as to match the Content-Length header, and you know that you can run some extra PHP code - such as shutdown stuff - without affecting the response to the user.
3. This way of serving content to the user is outdated and new strategies are showing up such as BIG PIPE. Drupal 8 already includes an implementation of such a rendering strategy.
4. Because streaming your content means YOU DO NOT KNOW HOW MANY BYTES YOU WILL BE STREAMING BEFORE STARTING TO STREAM the Content-Length header is ommited.
5. This is where fastcgi_finish_request() come in handy, because on the server side you know WHEN you have finished serving the page, and you could call this method to end the current connection and then move on to shutdown tasks.
fastcgi_finish_request() aims to solve this issue and is part of the PHP, but only available on select environments. Unluckily not on IIS with FastCGI.