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

21–30 of 107 posts

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

#21

Post by agwa »

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…

Putting security-critical logic in proxies is a violation of the End-to-End Principle, not an example of it. That doesn't mean it's a bad thing; as ragall notes, the End-to-End Principle doesn't make sense here.

You're correct that if the proxy removes all unknown headers, you're safe (with HTTP/2). But that sounds extremely inconvenient - before your application can use a new header, you have to talk to the team who runs the proxy. And popular reverse proxy software doesn't do that by default so it remains a huge footgun for the unwary. All completely avoided with FastCGI.

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

#23

Post by max_k »

I agree with the article, FastCGI is better than HTTP for these things.

Though I'd like to make another protocol known: Web Application Socket (WAS). I designed it 16 years ago at my dayjob because I thought FastCGI still wasn't good enough.

Instead of packing bulk data inside frames on the main socket, WAS has a control socket plus two pipes (raw request+response body). Both the WAS application and the web server can use splice() to operate on a pipe, for example. No framing needed. Also, requests are cancellable and the three file descriptors can always be recovered.

Over the years, we used WAS for many of our internal applications, and for our web hosting environment, I even wrote a PHP SAPI for WAS. Quite a large number of web sites operate with WAS internally.

It's all open source:

- library: https://github.com/CM4all/libwas - documentation: https://libwas.readthedocs.io/en/latest/ - non-blocking library: https://github.com/CM4all/libcommon/tree/master/src/was/asyn... - our web server: https://github.com/CM4all/beng-proxy - WebDAV: https://github.com/CM4all/davos - PHP fork with WAS SAPI: https://github.com/CM4all/php-src

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

#24

Post by nostrademons »

masfuerte wrote: post #18
nostrademons wrote: post #10

Earlier quoted context omitted.

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…

Can you recommend a reverse proxy that supports white-listing of headers? nginx doesn't seem to.

Had to Google since it's been almost 20 years since I used nginx directly:

https://serverfault.com/questions/1033131/filter-to-only-pas...

Set proxy_pass_request_headers off, and then explicitly proxy_set_header each individual header you want to forward to the variable representing it in nginx config.

Or just use CloudFlare Tunnel, which gives you a bunch of other DDoS and abuse protection and keeps your app server off the public Internet.

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

#25

Post by winstonwinston »

nzeid wrote: post #7
tombert wrote: post #2

Interesting. Most of the stuff I've done for reverse proxies has been pretty straightforward and just using the stuff built into Nginx, but I have to admit that it wouldn't have even occurred to me to use FastCGI if I needed something more elaborate. I used FastCGI a bit about ten years ago to "convert" some C++ code I wrote to work on the web, but admittedly I haven't used it much since then.

Also, embedded servers are now much much much more popular. Stuff an HTTP server directly into your application and do whatever you gotta do without gateways.

These are often not enough ‘battle-tested” and come with a warning to never expose to public internet. So then you put a WAF in front of it, and you are back to HTTP reverse proxy setup.

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

#26

Post by masfuerte »

nostrademons wrote: post #24
masfuerte wrote: post #18

Earlier quoted context omitted.

Can you recommend a reverse proxy that supports white-listing of headers? nginx doesn't seem to.

Had to Google since it's been almost 20 years since I used nginx directly: https://serverfault.com/questions/1033131/filter-to-only-pas... Set proxy_pass_request_headers off, and then explicitly proxy_set_header each individual header you want to forward to the variable representing it in nginx config. Or just use CloudFlare Tunnel, which gives you a bunch of other DDoS and abuse protection and keeps your app server…

Thank you, I somehow missed that.

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

#27

Post by nzoschke »

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 stdlib has good support on both the server side and user space. The coding agent makes a page-name/main.go that talks CGI and the server delegates requests to it.

It’s all “person scale” data and page views so no real need to optimize with fast CGI even.

What’s old is new again for agents!

1. https://housecat.com

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

#29

Post by athrowaway3z »

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 framing as well as browser support.

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

#30

Post by somat »

shevy-java wrote: post #14

I'd love for CGI to be updated, kind of merging what works and not really caring about what does not work. Getting a .cgi file to work on Linux is really easy. Naturally you get more leverage with e. g. rails, but there is also a lot more complexity and I really hate intrinsic complexity.

CGI and FastCGI are two different things in two different domains. Well the domains are not that different but enough that CGI solves a real problem and makes sense and FastCGI does not. CGI is the interface between a HTTP transaction and a process. It answers the question "How do we turn a HTTP request into executing a process?". FastCGI answers the question of "How do we turn a HTTP request into a FastCGI request". a convolution that leaves you asking "Why are we jumping through this hoop? Is FastCGI actually bringing anything to the table?, Is it actually more difficult to have a HTTP server instead of a FastCGI server if they are so trivially connected?

I am halfway convinced the only reason FastCGI exists is we had got in a mindset that executable code in a HTTP context had to run via the Common Gateway Interface and when we wanted to to change to a persistent process model it had to have the CGI name as well. Well FastCGI to the rescue it does exactly what HTTP does but is not HTTP and most importantly has CGI in the name.

As to the articles complaint, "A HTTP relay server had a bug. Therefore HTTP is intrinsically bad". Well.. it failed to convince me. I am not exactly in that domain(backend web development) so my view is not worth much. But I feel that your internal HTTP(application) servers should be built as if they were going directly on the open web. Then you put some relay servers in front in order to block, balance and route requests. But avoid putting too many smarts in the relay servers. A smart network is almost always a bad idea. try and stick with a dumb network and smart edges.

Post reply on HN