Skip to content
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

proposal: net/http: allow setting timeouts individually in Client #23100

alex-leonhardt opened this issue Dec 12, 2017 · 6 comments

proposal: net/http: allow setting timeouts individually in Client #23100

alex-leonhardt opened this issue Dec 12, 2017 · 6 comments


Copy link

@alex-leonhardt alex-leonhardt commented Dec 12, 2017

What version of Go are you using (go version)?

go1.9 darwin/amd64

Does this issue reproduce with the latest release?


What operating system and processor architecture are you using (go env)?

GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/c6/5xqsbcl95j713z7y5tz1cp6m0000gn/T/go-build047959207=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

It's not a bug; more a feature request. When calling a HTTP endpoint using http.Client; it'd be great if it was possible to individually configure the connection timeout from the response timeout and a generic timeout that would count for both. Reason I'm asking for this is to be able to fail fast when a endpoint just isn't there, vs wait for potentially longer when there is a endpoint and it's slow to respond. I've found some implementation of this, but it is much more "work" than it really should be.

Cloudflare's blog is pretty good, and much more concise, however, still more than I would have expected :

What did you expect to see?

  ConnectionTimeout: time.Duration,
  ResponseTimeout: time.Duration

What did you see instead?

  Timeout: time.Duration
@mvdan mvdan changed the title net/http.Client - set timeouts individually net/http: set timeouts individually in Client Dec 12, 2017
@mvdan mvdan added the NeedsDecision label Dec 12, 2017
Copy link

@titanous titanous commented Dec 12, 2017

@bradfitz I think this can be closed, because all of the timeouts mentioned are supported in http.Transport (and extensively explained in the two links provided).

Copy link

@alex-leonhardt alex-leonhardt commented Dec 13, 2017

My point is I guess more that it could be made much much easier to use than it currently is; needing to know to have to setup your custom http.Transport with a custom net.Dialer is more than I guess most people were after when they simply need/want to set the above 2 timeouts. The two mentioned are in my opinion the two most used and useful, hence also only asking for those two.

Either way, I believe it'd be great to have this in net/http by default, not everyone would will need to wrap their own http.Client for configuring these two timeouts.

@titanous titanous changed the title net/http: set timeouts individually in Client proposal: net/http: allow setting timeouts individually in Client Dec 13, 2017
@gopherbot gopherbot added this to the Proposal milestone Dec 13, 2017
@gopherbot gopherbot added the Proposal label Dec 13, 2017
Copy link

@rsc rsc commented Feb 5, 2018

This seems very specific, and it's already possible. It's unclear we need to thread it through in a second way, from Client. More generally we need a nicer Client, and instead of adding one thing at a time there should be a redesign at some point. @bradfitz is going to make a tracking bug for the things we'd want to fix in a new Client.

Copy link

@bradfitz bradfitz commented Feb 5, 2018

I filed #23707 as a meta bug for tracking http.Client improvements, which could/should include more timeout control.

Copy link

@alex-leonhardt alex-leonhardt commented Feb 7, 2018

Cool, I think I'm happy with it being part of the http.Client improvements in #23707 .
Thanks! 👍

Copy link

@bradfitz bradfitz commented Feb 7, 2018

Thanks. I'll close this one for now then.

@bradfitz bradfitz closed this Feb 7, 2018
@golang golang locked and limited conversation to collaborators Feb 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.