(u)WSGI must surely get a mention here?!
FastCGI: 30 years old and still the better protocol for reverse proxies
51–60 of 107 posts
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#52This 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).
In my experience having different serving paths for dev vs production is a recipe for annoying issues. I try to make dev as similar to prod as possible.
I’m not sure, I don’t dismiss fcgi outright here, I find the arguments for it compelling (not a huge fan of http for many reasons) but it has to be really worth it to break the consistency of using http everywhere.
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#53Earlier quoted context omitted.
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).
In my experience having different serving paths for dev vs production is a recipe for annoying issues. I try to make dev as similar to prod as possible. I’m not sure, I don’t dismiss fcgi outright here, I find the arguments for it compelling (not a huge fan of http for many reasons) but it has to be really worth it to break the consistency of using http everywhere.
If you want your dev environment to be as similar to prod as possible, and you use a proxy in prod, then you should use a proxy in dev also. I was presenting a solution to someone who doesn't want to do that.
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#54Earlier quoted context omitted.
In my experience having different serving paths for dev vs production is a recipe for annoying issues. I try to make dev as similar to prod as possible. I’m not sure, I don’t dismiss fcgi outright here, I find the arguments for it compelling (not a huge fan of http for many reasons) but it has to be really worth it to break the consistency of using http everywhere.
If you want your dev environment to be as similar to prod as possible, and you use a proxy in prod, then you should use a proxy in dev also. I was presenting a solution to someone who doesn't want to do that.
I think perhaps I was unclear. I don’t mean the entire dev environment should mirror prod (although it’s great if you can do this for end to end testing). I just mean it’s desirable if the process you’re working on operates the same way in dev as in prod.
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#55I think there is a lot of merit to this argument, however, FastCGI defers to CGI/1.1 for `PATH_INFO`, etc., which is lossy as it must be URL-decoded and therefore cannot represent encoded slashes, `%2F`. (Some implementations also collapse `//` to `/` in path, but this is an issue in various HTTP implementations too.)
It is less expressive than HTTP in ways that may or may not be important to your application; I prefer accurate URL handling.
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#56I 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 ca…
>>FastCGI is better than HTTP for these things.
FastCGI and HTTP are at two different levels. HTTP is for data transfer from, say, a browser and a server. FastCGI is for handling that data between the server and an application.
Just now I glanced at the article and it seems the author writes in a confusing way to imply that HTTP and FastCGI are interchangeable and they are not.
fwiw, I used fcgi for a decade for all our web customers.
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#57FCGI 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.
This is exactly how we used it.
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#58I 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 ca…
>>FastCGI is better than HTTP for these things. FastCGI and HTTP are at two different levels. HTTP is for data transfer from, say, a browser and a server. FastCGI is for handling that data between the server and an application. Just now I glanced at the article and it seems the author writes in a confusing way to imply that HTTP and FastCGI are interchangeable and they are not. fwiw, I used fcgi for a decade for all…
I feel like the author of an alternative protocol probably knows these things.
I think the author mentions HTTP because many people use it where they could be using FastCGI and just don’t.
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#59I’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.
> I still don't love how CGI uses environment variables.
Neither do I. They really only make sense in the context of a request which was actually to a CGI script resident in a document root - they're an exceptionally awkward way of describing other HTTP requests, especially ones which aren't being served from a document root. And there's a lot of information lost in translation, like the order and original capitalization of HTTP headers. (Not that these things are supposed to matter, but still.)
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#60I 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 ca…
>>FastCGI is better than HTTP for these things. FastCGI and HTTP are at two different levels. HTTP is for data transfer from, say, a browser and a server. FastCGI is for handling that data between the server and an application. Just now I glanced at the article and it seems the author writes in a confusing way to imply that HTTP and FastCGI are interchangeable and they are not. fwiw, I used fcgi for a decade for all…
And yet I’ve seen in production the (ab)use of HTTP where fcgi would’ve been a much better fit.