3 ms·

It's nice to see that Go's http and TLS libraries are getting even better. They're what attracted me to Go in the first place. Also, the coverage of the variou

It's nice to see that Go's http and TLS libraries are getting even better. They're what attracted me to Go in the first place. Also, the coverage of the various timeouts for HTTP requests is mostly new information to me. Is that something that nginx and apache usually take care of?

moomin 10y ago
I'm not a fan of Go, but its libraries seem top-notch.
- KirinDave 10y ago
  They are, unless you want to know what went wrong. Then the fundamental problems with the library design sorta beat you over the head.
kevinburke 10y ago
you can usually configure them, see for example http://nginx.org/en/docs/http/ngx_http_core_module.html#send_timeout http://nginx.org/en/docs/http/ngx_http_core_module.html#send... and http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout http://nginx.org/en/docs/http/ngx_http_proxy_module.html#pro... The difference is Nginx sets timeouts based on the time between successive byte reads or writes, so for example if you have a 30 second timeout and receive one byte every 29 seconds, you won't trigger Nginx's timeouts: https://kev.inburke.com/slides/reliable-http/#connect-timeout-requests https://kev.inburke.com/slides/reliable-http/#connect-timeou... Go generally prefers wall-clock timeouts for reading or writing the entire response, that is, if you don't get the whole thing in 30 seconds, return an error, regardless of when you received each individual byte. Although you can configure Nginx-style timeouts if you want.
ben_jones 10y ago
My personal experience with the Go stdlib is that it practices "defensive programming" pretty well. For example HttpClient defaults. It's what you would expect from a language with go's objectives, but it's still something I appreciate (even if it forces me to do things right when I don't want to!).
- zzzcpan 10y ago
  HttpClient has no usable defaults. In fact, you can't even make a usable file downloader because of the way it handles timeouts, you have to write your own.

moomin 10y ago

I'm not a fan of Go, but its libraries seem top-notch.

KirinDave 10y ago
They are, unless you want to know what went wrong. Then the fundamental problems with the library design sorta beat you over the head.

kevinburke 10y ago

you can usually configure them, see for example http://nginx.org/en/docs/http/ngx_http_core_module.html#send_timeout http://nginx.org/en/docs/http/ngx_http_core_module.html#send... and http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout http://nginx.org/en/docs/http/ngx_http_proxy_module.html#pro... The difference is Nginx sets timeouts based on the time between successive byte reads or writes, so for example if you have a 30 second timeout and receive one byte every 29 seconds, you won't trigger Nginx's timeouts: https://kev.inburke.com/slides/reliable-http/#connect-timeout-requests https://kev.inburke.com/slides/reliable-http/#connect-timeou... Go generally prefers wall-clock timeouts for reading or writing the entire response, that is, if you don't get the whole thing in 30 seconds, return an error, regardless of when you received each individual byte. Although you can configure Nginx-style timeouts if you want.

ben_jones 10y ago

My personal experience with the Go stdlib is that it practices "defensive programming" pretty well. For example HttpClient defaults. It's what you would expect from a language with go's objectives, but it's still something I appreciate (even if it forces me to do things right when I don't want to!).

zzzcpan 10y ago
HttpClient has no usable defaults. In fact, you can't even make a usable file downloader because of the way it handles timeouts, you have to write your own.