Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FastCGI: 30 years old and still the better protocol for reverse proxies

agwa.name

Post reply on HN
Print view View original

31–40 of 107 posts

Re: FastCGI: 30 years old and still the better protocol for reverse proxies

#31

Post by agwa »

athrowaway3z wrote: post #29

This seems like really bad advice or am i missing something? Using fastcgi requires you write your app to serve fastcgi. The upside of serving http/1.1 instead of fastcgi is that devs can instantly use their browser to test things instead of having to setup a reverse proxy on their machine. The bad parts of http/1.1 are fixed equally well by both http/2.0 and fastcgi. So just use http/2.0 and you get the proper frami…

Please see the section about untrusted headers - this is not fixed by HTTP/2.

You're right that being able to point your browser right at the app is very convenient. With Go, you can have a command line flag that switches between http.Serve (for development) and fcgi.Serve (for production).

Re: FastCGI: 30 years old and still the better protocol for reverse proxies

#32

Post by ragall »

nostrademons wrote: post #10
ragall wrote: post #4

Earlier quoted context omitted.

The end-to-end principle within a datacenter makes little sense and, as shown in the article, ends up enabling insecure behaviour.

It makes a lot of sense. Most large organizations are collections of independent teams, many of whom don't communicate with each other other than sending quarterly OKRs and status updates back to their VP. The E2E principle is what allows them to each do their thing, agnostic to what the other servers handling the request are doing, and then let higher levels of the organization reconfigure and provision the system b…

> Most large organizations are collections of independent teams, many of whom don't communicate with each other other than sending quarterly OKRs and status updates back to their VP.

You describe an organizational failure, where different teams are allowed to do whatever they like instead of having a proper platform team, which can enforce security and standards for the benefit of interoperability. It's not an argument in favour of transparent end-to-end behaviour in datacenters.

Re: FastCGI: 30 years old and still the better protocol for reverse proxies

#34

Post by wahern »

nostrademons wrote: post #3

This is quite an interesting article for its omissions. I remember the great FastCGI vs. SCGI vs. HTTP wars: I was founding a Web2.0 startup right at the time these technologies were gaining adoption, and so was responsible for setting up the frontend stack. HTTP won because of simplicity: instead of needing to introduce another protocol into your stack, you can just use HTTP, which you already needed to handle at th…

> The use of HTTP was basically the web equivalent of the End-to-End Principle [1] for TCP/IP.

I don't think the analogy works, not in the context of connection caching and multiplexing. An intermediate gateway multiplexing multiple HTTP requests over another HTTP channel, where that channel is the terminal leg directly to the listening service (i.e. requests aren't demultiplexed before hitting the application socket), fundamentally violates the logic to end-to-end in multiple ways. The analogy only works, if at all, if you preserve 1:1 connection symmetry.

All the reverse proxy exploits can be traced directly back to violating end-to-end.

If the analogy were true, then SMTP delivery across multiple MXs would be end-to-end as well. It's not, and you see many of the same issues as with reverse proxies, including messaging boundary desync'ing.

I guess you're trying to analogize HTTP requests as messages, but it falls apart almost immediately in the context of all the hairy details. The nature of TCP and HTTP semantics and the various concrete protocol details throws a wrench into things, with predictable consequences.

The end-to-end principle doesn't permit playing fast and loose with semantics. It demands very hard, rigid boundaries regarding state management and transport layering. That's the whole point. "Mostly" end-to-end is not end-to-end, not even a little bit.

Re: FastCGI: 30 years old and still the better protocol for reverse proxies

#35

Post by apitman »

> That said, using a vintage technology has some downsides. It was never updated to support WebSockets

With widespread browser support for WHATWG streams, it's pretty easy to implement your own WebSockets over long-lived HTTP requests. Basically you just send a byte stream and prepend each message with a header, which can just be a size in many cases.

Advantages over WebSockets:

* No special path in your server layer like you need for WebSocket.

* Backpressure

* You get to take advantage of HTTP/2/3 improvements for free

* Lower framing overhead

Unfortunately AFAIK it's still not supported to still be streaming your request body while receiving the response, so you need a pair of requests for full bidirectional streaming.

Re: FastCGI: 30 years old and still the better protocol for reverse proxies

#36

Post by agwa »

nzoschke wrote: post #27

I’ve rediscovered plain old CGI as a great way for users to “vibe code” custom pages on our platform. [1] The scenario is we have our first party task lists and data viewers, but often users want to highly customize it. Say build a Kanban view or a custom dashboard with data filters and charts. The box has a coding agent which means the user can code anything vs us building traditional report builder tools. Go’s stdl…

Do be aware that CGI, unlike FastCGI, has a pretty big footgun due to the use of environment variables to convey HTTP headers: https://httpoxy.org/

Go's CGI server implementation doesn't set $HTTP_PROXY so you're safe from that, but I still don't love how CGI uses environment variables.

Re: FastCGI: 30 years old and still the better protocol for reverse proxies

#37

Post by Induane »

shevy-java wrote: post #15
nostrademons wrote: post #3

This is quite an interesting article for its omissions. I remember the great FastCGI vs. SCGI vs. HTTP wars: I was founding a Web2.0 startup right at the time these technologies were gaining adoption, and so was responsible for setting up the frontend stack. HTTP won because of simplicity: instead of needing to introduce another protocol into your stack, you can just use HTTP, which you already needed to handle at th…

What I dislike about nginx is ... the documentation. I find it virtually useless because of that. Sadly httpd went the way of "let's make the configuration difficult"; I abandoned it when they suddenly changed the configuration format. I could have adjusted, but I switched to lighttpd (and also, past that point I let ruby autogenerate any configuration format, so technically I could return to httpd, but I don't want…

I've been copying/modifying the same nginx config file for like 15 years

Little tweak here, little tweak there...

Post reply on HN