-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not suitable for use with http.Serve #1
Comments
Hmm that is nasty. Not sure I see an obvious solution to this, it looks like it will always require ugly hacks. |
Here's a CL for Go that should fix this. https://go-review.googlesource.com/#/c/15832/ |
and a workaround we're using: https://gist.github.com/glasser/ac531523a027cbe3955d |
I got a simpler CL into Go: golang/go@b58515b So this should work without a workaround in 1.6. Issue in go repo: golang/go#12943 |
@glasser Thanks for the heads up! |
@glasser I'm curious what you ended up doing with this issue? I will need to handle proxy protocol in Go too... |
As described above, this should be fixed in Go 1.6. My gist above is an annoying workaround for 1.5. |
Cool thanks @glasser |
The library user can define a maximum time to wait for the PROXY protocol header, before failing out to normal connection. We can assume that a proxy in front of the service will send the PROXY header immediatelly. This solves the issue of clients getting block when getting the RemoteAddr() for an incoming connection that does not send any data. That is the case of http.Serve on go < 1.6 as described in armon#1
The library user can define a maximum time to wait for the PROXY protocol header, before failing out to normal connection. We can assume that a proxy in front of the service will send the PROXY header immediatelly. This solves the issue of clients getting block when getting the RemoteAddr() for an incoming connection that does not send any data. That is the case of http.Serve on go < 1.6 as described in armon#1
The library user can define a maximum time to wait for the PROXY protocol header, before failing out to normal connection. We can assume that a proxy in front of the service will send the PROXY header immediatelly. This solves the issue of clients getting block when getting the RemoteAddr() for an incoming connection that does not send any data. That is the case of http.Serve on go < 1.6 as described in armon#1
The library user can define a maximum time to wait for the PROXY protocol header, before failing out to normal connection. We can assume that a proxy in front of the service will send the PROXY header immediatelly. This solves the issue of clients getting block when getting the RemoteAddr() for an incoming connection that does not send any data. That is the case of http.Serve on go < 1.6 as described in armon#1
This isn't exactly a bug with this package, but we learned the hard way in production that this code (or anything implementing this interface) isn't suitable for use with
http.Server.Serve
. Might be worth mentioning in docs.Specifically:
http.Server.Serve
looks like:srv.newConn
callsrw.RemoteAddr()
, and if that's a proxyproto listener, it can block if the incoming connection doesn't actually send over any data. And this is beforego c.serve()
, so it's in the mainhttp.Server.Serve
goroutine!Workarounds for this seem pretty complex, unfortunately...
The text was updated successfully, but these errors were encountered: