3 ms·

One thing about Go developers that sort of baffles me is their desire to handle HTTPS. Yes, Go makes it easy to do so, but really you should be sticking your G

by xienze 10y ago

One thing about Go developers that sort of baffles me is their desire to handle HTTPS. Yes, Go makes it easy to do so, but really you should be sticking your Go app behind Apache, NGiNX, etc. instead of putting it directly on the Internet for reasons you've listed and more.

jerf 10y ago
Putting your Go webserver behind nginx will fix, by my count, only one of those, compression. Maybe 10% of a point for faking up HEAD support, but nginx converting a GET into a HEAD by simply dropping the body isn't very compelling. Putting your webserver behind nginx just to do it isn't very compelling. To get a win you really need to be doing something in nginx beyond merely just proxying. That's not really a Go-specific complaint, that's a complaint about a loooot of implementations of web stuff. Edit: Compression is less important than it sounds, too; for security reasons, you shouldn't compress dynamic content going over HTTPS, so nginx doing the compression only helps for HTTP, and it's only a handful of lines of code to implement it in your Go layer too so it's not a huge win. If nginx did fix a lot of those problems without having to think about it, it would be helpful, but it doesn't.
- sofaofthedamned 10y ago
  Quite right. Compression over TLS, although useful, is frowned upon for the reasons you state. I'm normally the sort of guy who puts everything behind HAProxy, I may still do that for convenience (certs in the same place etc) but imagine moving to a point where I put the Go programs behind, but in TCP mode.
- deleted 10y ago
  [deleted]
zacmps 10y ago
Why do you think go would be run behind a reverse proxy for TLS?
- xienze 10y ago
  Because otherwise you have to include in your application the config necessary to: * Enable compression, if desired. * Redirect HTTP requests to HTTPS. * Add headers for security best practices like OCSP stapling, DH params, HTTP STS, HPKP, etc. Those are really things best handled in the edge and not by your application. Your proxy is probably going to do a better job of these things than you are and the config will be simpler. Not to mention if you have to update any of those settings you can do a hot-reload of your proxy's config -- your Go app has to be recompiled. And oh yeah, the moment you have more than one Go app sitting behind your host you need a proxy anyway.

by xienze 10y ago

jerf 10y ago

Putting your Go webserver behind nginx will fix, by my count, only one of those, compression. Maybe 10% of a point for faking up HEAD support, but nginx converting a GET into a HEAD by simply dropping the body isn't very compelling. Putting your webserver behind nginx just to do it isn't very compelling. To get a win you really need to be doing something in nginx beyond merely just proxying. That's not really a Go-specific complaint, that's a complaint about a loooot of implementations of web stuff. Edit: Compression is less important than it sounds, too; for security reasons, you shouldn't compress dynamic content going over HTTPS, so nginx doing the compression only helps for HTTP, and it's only a handful of lines of code to implement it in your Go layer too so it's not a huge win. If nginx did fix a lot of those problems without having to think about it, it would be helpful, but it doesn't.

sofaofthedamned 10y ago
Quite right. Compression over TLS, although useful, is frowned upon for the reasons you state. I'm normally the sort of guy who puts everything behind HAProxy, I may still do that for convenience (certs in the same place etc) but imagine moving to a point where I put the Go programs behind, but in TCP mode.
deleted 10y ago
[deleted]

zacmps 10y ago

Why do you think go would be run behind a reverse proxy for TLS?

xienze 10y ago
Because otherwise you have to include in your application the config necessary to: * Enable compression, if desired. * Redirect HTTP requests to HTTPS. * Add headers for security best practices like OCSP stapling, DH params, HTTP STS, HPKP, etc. Those are really things best handled in the edge and not by your application. Your proxy is probably going to do a better job of these things than you are and the config will be simpler. Not to mention if you have to update any of those settings you can do a hot-reload of your proxy's config -- your Go app has to be recompiled. And oh yeah, the moment you have more than one Go app sitting behind your host you need a proxy anyway.