back

by eatonphil·11y ago·view on hn ↗
I guess it's great to know you /could/ do this in Go. But wouldn't anyone serious about these particular options just choose to apply them in Nginx? It's not like Go has completely kicked Nginx out of the mix. I still use it for static files (I trust/know Nginx caching) and for SSL termination (though yes, this /could/ be done in Go).

Would you use these options in Go or would you just set them at the reverse-proxy level?

2 comments
> wouldn't anyone serious about these particular options just choose to apply them in Nginx?

It sounds like you are assuming that everyone "serious" already is or should be using Nginx. Also one shouldn't assume that you'll always be using a reverse-proxy. Even when you are using a reverse-proxy, in my opinion it's good to keep that layer as "dumb" as possible, minimizing application-specific details. For example, setting certain security HTTP headers correctly often requires a deeper understanding of an application than one should expect from the reverse-proxy layer.

Slightly off topic, but it reminds me of why I think web application firewalls are misused: they try to plug security holes that should be treated as application bugs.

Sure, the first two — adding headers and rate limiting — can be done in nginx. I like secure.Config, though, because I don't have to remember header names and make sure I wrote them correctly, as Go compiler will throw error if I mistype something (BTW, that's the reason there's Referer method in http.Request - http://golang.org/pkg/net/http/#Request.Referer).

As for sessions, please do not use OpenResty's encrypted-session-nginx-module; check its issue tracker for examples of how not to do crypto: https://github.com/openresty/encrypted-session-nginx-module/...