Why bother with FastCGI? Why not just use reverse proxy HTTP instead? Why introduce yet another protocol when HTTP works fine?
I didn't write this, but I agree with it - https://ef.gy/fastcgi-is-pointless
I didn't write this, but I agree with it - https://ef.gy/fastcgi-is-pointless
Yeah, FastCGI introduces a whole other attack surface, but it's on a trusted boundary, at least. Mixing trust levels within content seems like one of the primary classes of security problems.
For instance it looks like multiple occurrences of the same header will be ignored, and it will just close the connection instead of returning status 400 on protocol errors - in the best case.
Sure, you can try to implement just the parts of the HTTP spec that you think you'll need, and hope for the best. But wouldn't you rather use a simpler protocol that you could implement fully without having to worry about subtle errors sneaking in because you parsed the request line slightly wrong, or because your proxy decides to send two X-Forwarded-For headers instead of one.
If you're writing in Java or C++ you'll be able to find a mature HTTP library that handles all of this for you, but if for whatever reason I were writing from scratch, I'd take a limited-purpose protocol like FastCGI any day.
That said, closing the connection when you get rubbish input is generally a perfectly reasonable strategy, especially behind a reverse proxy that'll clean up after you. And in the code that is only done at all if asio.hpp claims that the underlying (tcp or unix) socket is in an error state. At which point it is impossible to reply.
As for repeated headers, according to http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 all multi-line headers must be representable as a single header by concatenating the parts with commas. So there was simply no use case for implementing this.
And FastCGI is definitely not simpler or "more limited-purpose" in any meaning of the word. At least not if you insist on implementing the full spec, which includes fun things like the authorisation and filter roles. And I highly doubt you can convince any conformant implementation to parse duplicate headers for you.
So implementing a reasonable subset - e.g. clean queries for HTTP or merely the responder role for FastCGI - is a perfectly reasonable strategy. And given all that, I will take a text-based protocol that in a pinch I can query against directly with a web browser or telnet any day.