-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
x/net/http2: EOF when Transport received GOAWAY (http2 client) #14627
Comments
So Apple is sometimes returning errors in DATA frames, and sometimes in GOAWAY frames? I suppose we could note the most recent GOAWAY debug message (if any) and hold on to it if that ends up being the best possible way to fail your RoundTrip at EOF, if nothing more explicit hasn't come up in the meantime. |
Yah. I don't know why Apple is returning errors in GOAWAY frames. I just ran the test again to confirm that it is still the case. I'm not familiar with the HTTP/2 specification. Should I open an issue with Apple as to why they are returning errors in GOAWAY or is that a legit thing to do? Some way of accessing the GOAWAY debug message from Go could be useful, but do note that there are GOAWAY frames with no debug message after the ones with one. Alternatively I could just handle EOF and document that people should use |
No need to bug Apple. This is fine, if slightly unique behavior. I've demoted this to Go1.7Maybe because I believe you use x/net/http2 directly anyway, so timing doesn't matter as much. Also, I disappear for a month in approximately 8 hours. |
Works for me. Yes, using an Apple-signed certificate requires that I bring in x/net/http2 and use |
Update: Later this year I hope to be able to use net/http rather than x/net/http2 in cases where I don't need to setup a different certificate for the client. This is thanks to the Apple introducing JSON Web Tokens for Authentication rather than relying on certificates signed by them. If I could just use net/http even with a different cert, that would be great too, but a separate issue. |
Updates golang/go#14627 (fixes once bundled into std) Change-Id: Iae91d165df749e06549a25f9664ee416f115573f Reviewed-on: https://go-review.googlesource.com/24560 Reviewed-by: Andrew Gerrand <[email protected]> Run-TryBot: Brad Fitzpatrick <[email protected]> TryBot-Result: Gobot Gobot <[email protected]>
CL https://golang.org/cl/24561 mentions this issue. |
Thanks Brad. I'll test it out and report back. |
Upon updating I no longer get the EOF error, but I'm still not seeing the GOAWAY response from Apple. This the error shown when using an incorrect certificate causing a GOAWAY response:
The GODEBUG output is as follows:
As you can see, we receive more than one GOAWAY (despite only sending a single request). The first one contains Debug info whereas the later one does not. ref: RobotsAndPencils/buford#33 I don't know whether it's worth trying to capture that error message. This change is already an improvement over the more generic EOF, and I can simply document what to look for when users see a GOAWAY error. |
Sigh. I suppose we could track both the first and last or something. This is starting to feel very Apple-specific. |
It certainly does seem like an odd Apple thing, but I don't have experience with other HTTP/2 APIs to compare against. |
I pulled your changeset which does what you intended.
Now I should be able to detect this error and parse the JSON in the debug parameter to return the appropriate error code "BadCertificateEnvironment". Are you happy with that change though? |
CL https://golang.org/cl/24600 mentions this issue. |
I'm happy enough. |
(Once I saw the spec mentions multiple GOAWAY frames, I didn't feel that it was too Apple specific anymore) |
Thanks for exporting Or at least it should. Haven't had any luck type asserting it back to GoAwayError yet. resp, err := s.Client.Do(req)
if err != nil {
if e, ok := err.(http2.GoAwayError); ok {
log.Printf("GOAWAY %+v", e)
return "", errors.New(e.DebugData)
}
return "", err
} Go 1.7 beta2 (go version devel +fca9fc5 Thu Jun 16 19:45:33 2016 +0000 darwin/amd64) It seems to not propagate up through to Client.Do. Somewhere "Post url" is being prepended to the text. |
This does the trick:
Hopefully that doesn't miss out on anything important vs Client.Do, but it's not like I should need to follow redirects anyway. [update: well, nil Transport for DefaultClient, but no worries] |
So here's the odd thing. After switching from Client.Do to calling RoundTrip directly, I'm only receiving one GOAWAY. Without CL https://go-review.googlesource.com/#/c/24600 applied, this is the output I now see:
|
No clue. I don't control what Apple's server sends you. Maybe your request differed, or maybe you hit a different Apple backend. Or maybe it's a timing thing on their side. |
Yah, hard to say. It doesn't seem like a bad idea to merge multiple GOAWAY errors regardless. Thanks again for working on this. Much appreciated. |
The http2 spec permits multiple GOAWAY frames if the conditions change. Merge their error messages together, preferring the first non-empty debug data, and first non-ErrCodeNo error code. Updates golang/go#14627 Change-Id: I073b9234d71f128ed0713f09a24c728b56d7c1ae Reviewed-on: https://go-review.googlesource.com/24600 Run-TryBot: Brad Fitzpatrick <[email protected]> Reviewed-by: Andrew Gerrand <[email protected]>
Updates x/net/http2 to git rev 8e573f40 for https://golang.org/cl/24600, "http2: merge multiple GOAWAY frames' contents into error message" Fixes #14627 (more) Change-Id: I5231607c2c9e0d854ad6199ded43c59e59f62f52 Reviewed-on: https://go-review.googlesource.com/24612 Run-TryBot: Brad Fitzpatrick <[email protected]> Reviewed-by: Andrew Gerrand <[email protected]> TryBot-Result: Gobot Gobot <[email protected]>
CL https://golang.org/cl/24585 mentions this issue. |
Please answer these questions before submitting your issue. Thanks!
go version
)?go version go1.6 darwin/amd64
go env
)?GOHOSTARCH="amd64"
GOHOSTOS="darwin"
Run Buford's push example with a development certificate against the production environment.
RobotsAndPencils/buford#33
Expected a status code and JSON response
{"reason":"BadCertificateEnvironment"}
This is the debug output from a similar request:
Client.Do(req) returned an EOF error.
We're not sure if this is an issue with how x/net/http2 is handling GOAWAY and/or a problem with how Apple is returning this particular error.
/cc @groob
The text was updated successfully, but these errors were encountered: