[flagged]
FastCGI: 30 years old and still the better protocol for reverse proxies
71–80 of 107 posts
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#72The untrusted header problem could potentially be fixed by having the reverse proxy embed all the trusted information in a specific header, and then it just has to make sure that one header is stripped from the request. Unfortunately, there isn't (yet) a standard for that.
Or you could use something like haproxy's proxy protocol (although that may not support all the information you want, and doesn't work for multiplexing).
Edit: actually the "Forwarded" header kind of fills that niche. Although you may want extensions for things like the client certificate.
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#73The untrusted header problem could potentially be fixed by having the reverse proxy embed all the trusted information in a specific header, and then it just has to make sure that one header is stripped from the request. Unfortunately, there isn't (yet) a standard for that. Or you could use something like haproxy's proxy protocol (although that may not support all the information you want, and doesn't work for multipl…
Unfortunately, it appeared too late, and the relevant support is now far less complete than that for `X-Forwarded-*`.
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#74I was reading the article and thinking, I wonder what that proxy I'm using in Apache is using, it's really fast and I've had a lot of luck with it. OMG, so I've been using FastCGI all this time and had no idea, well that's awesome. :)
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#75The untrusted header problem could potentially be fixed by having the reverse proxy embed all the trusted information in a specific header, and then it just has to make sure that one header is stripped from the request. Unfortunately, there isn't (yet) a standard for that. Or you could use something like haproxy's proxy protocol (although that may not support all the information you want, and doesn't work for multipl…
FastCGI has "parameters" and HTTP headers are special parameters starting with "HTTP_" (mimicking CGI's environment variables). All parameters not starting with "HTTP_" can be trusted because only the web server (= FastCGI client) can construct them.
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#76I'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".…
> Is FastCGI actually bringing anything to the table?,
Yes; it removes the need for the application server to perform parsing of HTTP, which is notoriously difficult to consistently do safely. The application server can use the safer and simpler FastCGI protocol rather than try to support the full HTTP spec.
> Is it actually more difficult to have a HTTP server instead of a FastCGI server if they are so trivially connected?
IME, yes. HTTP (the spec) is full of footguns. FastCGI has fewer footguns. HTTP requires a long dependency chain in your application. FastCGI requires maybe a single library.
> But I feel that your internal HTTP(application) servers should be built as if they were going directly on the open web.
I feel that too, but which developer do you know writes their own HTTP server inside their application? They all use the most popular server via a library or framework, almost all of which warn not to open that to the public internet.
What do you propose they do? They use a framework/library and get a warning not to expose it to the public internet, they don't use a framework/library and odds are good that they coded some vulnerability into it.
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#77I 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…
> imply that HTTP and FastCGI are interchangeable and they are not.
But they are interchangeable!
FastCGI and HTTP/1.1 are indeed on the same level. Both are transport protocols for HTTP requests.
It would be technically possible to implement FastCGI as alternate transport protocols in browsers and web servers, just like HTTP/2 (SPDY) and HTTP/3 (QUIC) are alternate transport protocols for HTTP requests.
(This is not what the article and my comment are about, as others already pointed out.)
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#78> 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…
Please be aware that there is a web standard for this since quite some time. See server-sent events and the EventSource interface:
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent... https://developer.mozilla.org/en-US/docs/Web/API/EventSource
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#79FastCGI is theoretically better does not make it the easier choice in reality, the success of HTTP is just another case of "worse is better"