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

41–50 of 107 posts

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

#41

Post by nzeid »

winstonwinston wrote: post #25
nzeid wrote: post #7

Earlier quoted context omitted.

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.

I've always chuckled at this. Just don't used bad HTTP server libraries. I wouldn't put something like that on my intranet either.

But even if you disagree with me the point is that I can count on only one hand the number of times I went "oh man, I need a FastCGI middle end".

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

#42

Post by toast0 »

Animats wrote: post #40

FCGI is also an orchestration system. It launches more server tasks when the load goes up, shuts them down when the load decreases, and launches new copies of tasks if they crash. It's like single-system Kubernetes.

> It launches more server tasks when the load goes up, shuts them down when the load decreases

In my experience, this isn't a good feature. It sounds nice, but it can often mean everything runs fine while your load is low, but when your load gets high, you spawn more workers and run out of memory. It's much better to have a static number of workers in my experience.

Crash recovery is handy, if needed though.

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

#43

Post by mikestorrent »

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…

Nginx is extremely well represented in AI training material, so virtually every decent model - even locally hosted ones - can deliver you solid answers about its config settings.

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

#44

Post by toast0 »

kccqzy wrote: post #6
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 HTTP semantics are useful for anyone developing a web app but the wire protocol of HTTP itself is awful. Multiplexing didn’t arrive until HTTP 2.0 for example. So using HTTP for communication between a reverse proxy and a backend is very wasteful. There are security issues, such as when different parsers could even disagree on where the boundaries of a request ends. Google for example has long wrapped HTTP into t…

> Multiplexing didn’t arrive until HTTP 2.0 for example. So using HTTP for communication between a reverse proxy and a backend is very wasteful.

HTTP 2.0 multiplexing is tcp in tcp, it's asking for trouble. Just open more connections and let tcp be your multiplex. Depending on your connection rate, you can't really do 64k connections per frontend ip to each service ip:port, but if your rate isn't too high, 20-30k is feasible. most http based applications don't need or benefit from anywhere near that level of concurrency on frontend to backend. But if it's not enough, you can add more ips to the frontend or backend, or more ports to the backend.

I'm pretty sympathetic to the argument for FastCGI or similar as the protocol for frontend to backend though; having client set headers clearly separate from frontend set headers is very nice, and having clear agreement on message boundaries is of obvious value. Unless you're just doing a straight tcp proxy, in which case ProxyProtocol is good enough to transfer the original IPs and then pass data as-is.

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

#45

Post by PunchyHamster »

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.

Embedding http server (or fcgi one for that matter) is trivial in most languages and also makes local development simpler. CGI was horrible idea back then and it continues to be

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

#47

Post by ebb_earl_co »

scotty79 wrote: post #33

What I'd like to see is someone creating local caching proxy for modern https infested world. I'm fed up with downloading same packages 100 times.

I’m in the same boat. Am trying to figure out how to configure Vinyl cache (née Varnish) in my home lab.

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

#48

Post by Animats »

toast0 wrote: post #42
Animats wrote: post #40

FCGI is also an orchestration system. It launches more server tasks when the load goes up, shuts them down when the load decreases, and launches new copies of tasks if they crash. It's like single-system Kubernetes.

> It launches more server tasks when the load goes up, shuts them down when the load decreases In my experience, this isn't a good feature. It sounds nice, but it can often mean everything runs fine while your load is low, but when your load gets high, you spawn more workers and run out of memory. It's much better to have a static number of workers in my experience. Crash recovery is handy, if needed though.

It's useful if you have multiple FCGI programs that handle different kinds of requests. Depending on what's being requested, programs start up and shut down.

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

#49

Post by sroussey »

kccqzy wrote: post #6
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 HTTP semantics are useful for anyone developing a web app but the wire protocol of HTTP itself is awful. Multiplexing didn’t arrive until HTTP 2.0 for example. So using HTTP for communication between a reverse proxy and a backend is very wasteful. There are security issues, such as when different parsers could even disagree on where the boundaries of a request ends. Google for example has long wrapped HTTP into t…

Don’t forget http pipelining!
Post reply on HN