So you should at least use this timeouts on every go net/http client/server you use! Client It is not as fine grained as with the later bespoken solutions, but it will help you to prevent the most obvious problems: Net/http gives you the possibility to set a timeout for the complete transfer of data (setup, headers, body). You should at least do this: The easy path there is only a certain amount of headers that will be send) We still have to think and care about timeouts in the header as there are certain DOS attacks that play with malformed headers, or never closing a header ( SLOWLORIS DOS attack) but we will come to this in a later point of the post. The other ones are most of the time shorter and similar in every setup. During receiving/sending the header informationĪs you already might expect from our two examples in the introduction, the timeout that we have to care about the most is the one regarding the body.There are mainly three different categories of timeouts that can occur: (If not, Wikipedia is a good starting point for that) I assume you have a basic understanding of the TCP and HTTP protocols. So never use the standard go http client/server! It will break your production system! (Happened to me, as I forgot my own rule ones) What type of timeouts occur in a HTTP connection? That is why we have to set the timeouts, so that they fit our use case! So, for what scenario should the standard lib be optimized? Trust me, you do not want to decide that for millions of developers around the globe. So if that REST API you access is broken in any way that it keeps the connections open without sending you the data you need, you want to prevent it from doing so. => The timeout should be not more than 10 seconds, as anything that takes longer would mean, that you are keeping that connection open for to long and starving your application as it only can have X (depending on system, configuration and coding) open connections. This normally should take at most a few seconds per connection => The timeout for the connection should be longer than five minutes, because anything less would break your application by canceling the download in the middle (or third, or whatever percentage) of the file.Ģ) Accessing a REST API with a lot of concurrent connections. With an average (german) internet connection this would take round about five minutes. Imaging following different use cases of the go net/http client:ġ) Downloading a big file (10GB) from a webserver. To not break things! Timeouts are a highly individual setting and in more of the cases a to short timeout will break your application with a unexplainable error, than a too long one (or in GOs case none) would. The go core team decided to not set any timeouts at all on the standard net/http client or server config and that is a real sane decision. Why you should not use the standard net/http config? Give them a visit after you read this post and see how things have changed in such a short time □ The complete guide to golang net/http timeouts.The following two blog posts inspired me to revise the net/http timeouts, as the linked blog post are at some parts outdated: ID string `json:"id"` Name string `json:"name"` }įetchData(ctx context.Context, id string) (*Data, error)įunc New(baseURL string, client *http.Client, timeout time.Or a less click baity title: An introduction to net/http timeoutsįirst of all, as you may already recognized from the titles, this blogpost is standing on the shoulder of giants. "context" "encoding/json" "errors" "fmt" "net/http" "time" )ĮrrResponseNotOK error = errors.New( "response not ok")
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |