It would help a lot if someone could describe *why* interpreting higher-level protocol details (auth, redirects, cookies) is a bad thing. Also, retries aren't necessarily part of that "higher-level protocol" list, but I don't understand well enough to decide.
The reality is, I'm very likely going to use the transport for redirects anyway. On Monday, December 11, 2017 at 1:26:05 AM UTC-8, Kevin Conway wrote: > > A few of us had a very short discussion on the subject here: > https://groups.google.com/forum/#!topic/golang-nuts/rjYdaFM5OBw > > Almost all go code I've seen that requires an HTTP client takes an > `*http.Client` as one of the parameters. This doesn't leave consumers with > many other options than to leverage the `http.RoundTripper` interface that > is consumed via `http.Client.Transport` and implemented by > `http.Transport`. I've seen a great deal of success in using that interface > to implement resiliency features like retries even though the documentation > explicitly forbid using the `http.RoundTripper` for that purpose. My team > has fallen to using a decorator pattern where we define all new > functionality as an `http.RoundTripper` and apply it with a > `func(http.RoundTripper) http.RoundTripper`. Ex: > > var client = &http.Client{ > Transport: Retry(TImeout(Log(&http.Transport{}))), > } > > On Sun, Dec 10, 2017 at 1:19 PM Alex Buchanan <buchan...@gmail.com > <javascript:>> wrote: > >> I'm considering adding http client retries to an existing library, owned >> by someone else, in order to add resiliency to errors such as http 503. I'd >> like to keep the changes as minimal as possible, with maximum effect, as >> usual. I'm eyeing http.Client.Transport. Possibly I could use that to wrap >> the DefaultTransport, intercept responses, check the code against some >> rules, and retry on failure. >> >> Am I on the right track here? >> >> Thanks, >> Alex >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.