There is commit that has added a test for another issue. But as it spawns a server, it doesn't see the problem when using custom transport.
The request context is checked here but it only checks for deadline and not cancelations.
Also as must people use the DefaultTransport this bug does not show itself. But it is an undocumented behavior which either needs to be fixed(which is an easy task) or it must be documented that a RoundTripper must handle this.
The text was updated successfully, but these errors were encountered:
A RoundTripper should check for the request context becoming done, either from a timeout or from an explicit cancelation.
Even if Client.Do checked for an already-canceled context, a request context could still be canceled after the call to RoundTrip. In this case, it seems obvious that RoundTrip needs to handle the cancelation. Since RoundTrip needs to handle cancelation in this case, any check in Client.Do will be redundant.
Perhaps there could be additional documentation on RoundTrip explicitly stating that it should honor the request context becoming done, but it seems to me to be implicit in the existence of request cancelation. If the RoundTripper doesn't honor the context being canceled, then canceling the context will obviously not cause RoundTrip to return.
I agree with your argument. However, if you check the second link, context is being checked for deadline already. So we can also argue that this check is redundant as well; unless timeouts and cancellations are logically different from the net/http point of view.
However, if you check the second link, context is being checked for deadline already.
The only uses of that function that I see are to determine whether to create a new context.WithDeadline when Client.Timeout is set: If the request has a context that expires before the timeout, then don't bother setting a new deadline.
Nothing that I can see checks to see if the deadline has already expired.