Hacker News new | past | comments | ask | show | jobs | submit login

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

Reverse proxying isn't the same. Information that's critical to some apps, like client certs or socket info, isn't available without hacking up custom headers and mixing that trusted data in with the untrusted client message. Due to HTTP's supremely obtuse parsing rules, this can be exploitable even when being defensive. I've personally seen this in SIP proxing (ganked the parsing from HTTP) leading to simply unparseable messages due to irreconcilable differences in deployed software.

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.

If you want reverse proxy, run relayd. But slowcgi (and therefore bgplg, man.cgi, etc.) already use fastcgi.

Unsurprisingly his "400-ish line C++ header that implements an HTTP server" falls far short of supporting the full HTTP spec.

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's because the code was never meant to be used in production. It was meant to be used on a unix socket behind an nginx instance, which pretty reliably fixes up almost all the slight nuances and omissions in the protocol.

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.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact