FOS is not compatible with IIS about fos HOT 3 OPEN

I once searched for ways to make Fos/FastCgi work with IIS, but I honestly can't remember finding any good info on this; you seem to be much more aware of how it works. Do you have any links to some good reading material on this?

from fos.

I have been working on this one for the last couple of days since our organization generally prefers IIS. We're a mostly Windows shop so nginx/mono isn't really our thing, though I currently have my changes working with nginx. We have an external component that is not thread-safe and needs to be used in a web application. So unfortunately ASP.NET doesn't work for us--which is how I landed on your project.

It appears the best way to do this in C# is to P/Invoke to get the handle from StdIn and use that to open a FileSteam because unfortunately the .Net Socket API doesn't allow creating sockets from a handle. I see the .net core team has a work item to allow this, but it hasn't moved for a while. So I've been reading through the Fos/FastCGI code trying to decide what the most surgical change would be to support this. However, the approaches I have tried so far I do not like because they will require a lot of code churn. There are two problems:

1. The Fos/FastCGI code is very socket oriented. It appears to expect to accept connections for each new record. It maintains a dictionary of open sockets to records and reads them all in a loop. A FileStream would not have this mapping of connections to records.

2. A FileStream would be a continuous stream and would require logic to split the incoming records from each other.

from fos.

Wow, IIS seems really strange! However, I'd certainly love to get it working with Fos.
The main difference - and you said it yourself - is that Fos does one Socket per Request (that's how the servers I worked with do it anyways), while with IIS we'd have to multiplex connections over a single communication channel.

Before we delve into this we must really understand how IIS does this, because if multiple requests are multiplexed over a single channel, any FastCGI record may come in anytime, so we'd have to parse incoming FastCGI records and index our Requests by their Ids.
This should probably work with Sockets as well, with just one possible exception: Maybe data comes through the sockets in chunks so small (or so fragmented) that it's not even possible to obtain the RequestId of the next Record, so we don't know which request it belongs to, leading to a big problem.

This problem is most likely the reason (although I can't remember for sure) why I indexed Requests per Socket. I believe I even have unit tests that feed the main loop byte per byte to test if this works.

from fos.