I Want Off Mr. Golang's Wild Ride

Re:I Want Off Mr. Golang's Wild Ride by fhood on Friday February 28, 2020 @11:03AM (#22443670)

The http client isn't always directly exposed. I agree with the author. Context is a per request object and timeout should be able to function on a per request basis. Client is often shared and reused, and thus not always exposed in certain design patterns. If context has a timeout why doesn't it work as you would expect?

Also, now that I think about it, why does the basic http.get call mentioned in every go networking tutorial not have a default timeout?

[ Parent | on HN ]

Re:I Want Off Mr. Golang's Wild Ride by dilap on Friday February 28, 2020 @11:17AM (#22443804)

(I have never personally used context, so I'm not so sure what the expectations are with that.)

Looking at the http docs, I don't see any reason to believe setting a context for a request would control timeouts.

If the complaint is, "the http library API does not provide a way to set timeouts on a per-request basis," then OK, I guess, that's true, but I don't see why that should be a huge issue (just use different clients for the different timeout values you need).

But if you really don't want to do that, it should be easy enough to access the underlying network connection and set the timeout before reading the body, though I've never done this.

What Go is doing here still seems very reasonable from my perspective...

[ Parent | on HN ]

Re:I Want Off Mr. Golang's Wild Ride by fasterthanlime on Friday February 28, 2020 @12:03PM (#22444211)

Author here, the article was actually wrong - I meant to expose yet another timeout you can set on HTTP requests, I've updated it to include that one, and be clearer on what `idletiming`'s purpose is.

[ Parent | on HN ]