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.

Reply via email to