Re: Best practice to intercept HTTP requests

[Andrew Gerrand]

+golang-dev

On 15 April 2014 00:15, Burcu Dogan <j...@google.com> wrote:

What's the best way to intercept HTTP/S requests to add authorization headers? http.RoundTripper says, implementations should not alter the request with adding auth related headers or handle responses.

Like the current oauth package does it, by cloning the request:

https://code.google.com/p/goauth2/source/browse/oauth/oauth.go#273

I'm thinking about providing a client impl similar to http.Client. I also wonder why it doesn't implement a "Client" interface, so that multiple implementations could have been provided.

Go 1, basically. Given the chance to go back we might make Client an interface.

The current version provides a Client method that returns a Client:

https://code.google.com/p/goauth2/source/browse/oauth/oauth.go#174

Andrew 

[Russ Cox]

We made Client an implementation precisely so that there would not be other implementations. There's a lot of code there that is easy to get wrong; it's hard enough to get one implementation right. I haven't seen a compelling case for multiple Client implementations yet. Even if we had it to do over again, I wouldn't make Client an interface.

The RoundTripper is usually what you want to implement to do custom transports and such. You can send a different request than you received, just don't edit the original: make a copy instead. This makes sure that callers doing retries or using the same Request.Header for multiple concurrent requests do not see intermediate states.

Russ

[Burcu Dogan]

+campoy

> just don't edit the original: make a copy instead.

This is what I wanted to confirm. Earlier, campoy pointed to the same solution. Docs say the following, and it's not quite clear if it is about immutability of the req object, or a suggestion not to alter the behaviour at the RoundTripper level.

"RoundTrip should not modify the request, except for consuming and closing the Body."

Problem solved. Thanks.

--
Burcu Dogan