I really don't like during the close as a condition of calling Error. Is there any reason we can't tie the body lifecycle to the lifecycle of the readseeker?

I don't like it much either.

The problem is that there may be many HTTP requests created by each HTTPReadSeeker. Each call to Read can potentially cause a new HTTP request, whose response body needs to be closed. That's why I was associating them with the error object.

How about keeping a slice in the httpReadSeeker struct that tracks every response body that was associated with an error condition, and closing all of those when the Close method is called?

@aaronlehmann This is how it was before. Actually, there was only one request open at any time. If it was still open on the Close, it would have the body closed, as well.

I guess the question here is whether it's reasonable to close the body on the next Read call. For example, should we allow code that does this:

for ... {
        _, err := readSeekCloser.Read(p)
        if err != nil {
                if httpError, ok := err.(*transport.HTTPError); ok {
                        go doSomethingAsyncWithTheBody(httpError.Resp.Body)
                }
        }
}

This would be unsafe in the model where we only allow one open response body a time. But it seems like a weird case, and thinking about it some more, breaking this kind of code is probably better than potentially keeping many sockets open until the HTTPReadSeekCloser is closed, potentially hitting resource limits in the mean time.

So I'll move the body closing from Error to Close/reader and keep at most one response body open at a time, if you think that's reasonable.

Updated to close the Body of a response to an unsuccessful request on the next call to Read or Seek (before issuing a new request), or Close.

Updated again to avoid exposing the response through an error return. Instead, the HTTPReadSeeker takes a callback function that generates errors.

Can this statement be in (*httpReadSeeker).Seek? I think we can avoid having both seekOffset and offset.

Let's add a comment on the importance of this statement.