net/http: make Transport use GetBody, retry requests when no bytes were written #18241
This rolls back https://golang.org/cl/27117 partly, softening it so it only retries POST/PUT/DELETE etc requests where there's no Body (nil or NoBody). This is a little useless, since most idempotent requests have a body (except maybe DELETE), but it's late in the Go 1.8 release cycle and I want to do the proper fix. The proper fix will look like what we did for http2 and only retrying the request if Request.GetBody is defined, and then creating a new request for the next attempt. See https://golang.org/cl/33971 for the http2 fix. Updates #15723 Fixes #18239 Updates #18241 Change-Id: I6ebaa1fd9b19b5ccb23c8d9e7b3b236e71cf57f3 Reviewed-on: https://go-review.googlesource.com/34134 Run-TryBot: Brad Fitzpatrick <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Tom Bergan <email@example.com>
I'm not convinced about GetBody as an abstraction - it's not natural when using some kinds of obviously-retriable bodies such as files. Why not just seek to the body start if it implements io.Seeker? (you'd probably want to make that behaviour opt-in rather than opt-out).
But since you need an opt-in anyway, this seems like a reasonable opt-in. And we can't change our previous Close behavior, so seeking back to the beginning of a closed file obviously isn't going to work. Plus the more experience I have with type sniffing magic, the more it bites me. I like the explicitness of GetBody. GetBody is not just for Transport retries on network failures, but also Client redirects, replaying the request body. Trying to reuse the same Body while coordinating across those two layers (not forgetting http2) and without adding new API surface seems like it'd be gross.
I'm not sure this is the best place to discuss GetBody, though.