Comment by athrowaway3z
21 hours ago
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.
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.
1 reply →