-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Custom Transport #227
Comments
Thanks for opening the issue, @adrianliechti! The recommended way for injecting a custom HTTP client is to start from
Is the transport that you are trying to inject not of type *http.Transport? Otherwise it should be possible to inject it by initializing it in the HTTPClient object that you pass in through |
Ciao @averche, Thanks for hinting me to the DefaultConfiguration Builder. Could you think of something like this: if transport, ok := c.client.Transport.(*http.Transport); ok {
// Adjust the dial context for unix domain socket addresses.
if strings.HasPrefix(configuration.Address, "unix://") {
transport.DialContext = func(context.Context, string, string) (net.Conn, error) {
return net.Dial("unix", strings.TrimPrefix(configuration.Address, "unix://"))
}
}
if err := configuration.TLS.applyTo(transport.TLSClientConfig); err != nil {
return nil, err
}
} I think that supporting e.g. http.RoundTripper instead of http.Transport would allow more flexible use of this library. I will optimize my hack but keep it for the moment while excitingly watching the progress of this repo |
We could definitely consider this though I'm a bit concerned that it would silently turn off TLS & unix socket support. We would need to properly error out in the cases where these settings are provided in conjunction with a non-standard transport. I'll be away on vacation for a bit but will think about this a bit more :) |
I'd be happy with this kind of option - if folks override the transport then they should apply the same settings to it if the existing client can no longer do it. |
amazing! thanks a ton!! |
Currently, the New-Constructor throws an error, if a client uses a wrapped transport.
Maybe you could consider to allow this optionally
In my case, I would love to override the transport to allow tunneled connections. Other use cases might be to include OpenTelemetry Tracing Wrappers or similar
My current workaround is to set a dummy client, construct the client and then override the transport afterwards.
But I would prefer a more official way :)
Cheers, and thank you for this new client!
The text was updated successfully, but these errors were encountered: