Closed dsolonenko closed 3 years ago
Thank you for your report! I see the issue, yet I am not sure how to solve it now. It is, as you pointed out, a result of architecture flaw that started with http.Client
and was adopted here.
The only alternative I can currently think of to keep using http.Client
is to create some local server that will get all the calls (by changing the url to something like https://localhost:88888/<ORIGINAL_URL>
) but it will have many other issues with encoding the url, lifecycle management and using parameters. I am not keen to start exploring this, and would love to hear other suggestions.
Hello @enoodle, agree, having a local http client proxy does look like an overkill :)
Another options is to provide a wrapper for the http client's transport http.RoundTripper
. The traces would be less accurate, but it would be possible to use the http client as is in the third party services. This seems the approach that Stackdriver tracer is using https://cloud.google.com/trace/docs/setup/go
Cool I will sure be taking a look into this and put it in our road map. I am a bit swamped at the moment with other things so I am not sure when exactly I will get to it.
It is quite useful to automatically wrap http requests going through
http.Client
withepsagonhttp.Wrap
. Unfortunately this does not work with official golang client for services like Heroku Platform API for example: https://github.com/heroku/heroku-gobecause
ClientWrapper
cannot be used in place ofhttp.Client
.This looks like a weird golang design choice to make
http.Client
a struct instead of interface. But it would be great to explore some alternatives that would not require forking the service to acceptClientWrapper
.