-
Notifications
You must be signed in to change notification settings - Fork 224
Force TLS negotiation to only support HTTP/1.1 - Issue #298? #299
Conversation
Seems OKTA has a broken implementation of HTTP2? There seem to be some quirks with they way golang handles HTTP2 requests (specifically when receiving GOAWAY frames) golang/go#20979, which result in the HTTP2 connection not terminating.
This does indeed appear to fix #298 |
transCfg := &http.Transport{ | ||
Proxy: http.ProxyFromEnvironment, | ||
TLSHandshakeTimeout: Timeout, | ||
DisableKeepAlives: true, | ||
MaxIdleConnsPerHost: -1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are these two settings also necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These weren't required in our repro. DisableKeepAlives
makes the client setup a new TLS connection for each request. Though, that's the behavior I'm already seeing without it explicitly set.
This fixes #298 in our environment as well, however, I've reduced it down to a minimal patch that still works:
I don't yet understand why though. |
Default is HTTP1, says the Go docs. https://golang.org/pkg/net/http/
Still, better to be explicit. |
Ok, I'm going to modify this PR to match @sdann's change and merge. It'd be nice to understand this behaviour better though Update: an alternate PR apparently fixes the problem in a way that makes more sense to me. Feedback appreciated, since I haven't been able to repro myself yet. |
Superseded by #300 |
Seems OKTA has a broken implementation of HTTP2?
There seem to be some quirks with they way golang handles HTTP2 requests (specifically when receiving GOAWAY frames) golang/go#20979, which result in the HTTP2 connection not terminating.