You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Both #2404 and internal issues I've been looking at for Google Cloud client libraries have required customization of the HttpMessageHandler used by gRPC. GrpcChannelOptions provides the HttpClient property which allows a caller to take complete control of the client used... but in our case we really just want to tweak some options, without having to reproduce all the code present in this repo to work out which handler to create in what situations.
Describe the solution you'd like
A couple of options spring to mind:
Provide more properties on GrpcChannelOptions, and use those to automatically populate properties on any HttpMessageHandler constructed by gRPC
Provide a Action<HttpMessageHandler> ConfigureMessageHandler callback on GrcpChannelOptions, which we'd probably want to call on each individualHttpMessageHandler constructed (so if there's a chain of them, the callback doesn't have to walk the chain). Callers would then need to know how to configure multiple different types of handler, but it does provide complete flexibility.
Potentially both options could be implemented.
Describe alternatives you've considered
I haven't had any better ideas than the ones above, but I'm certainly not wedded to those - if there are better options, that's great. I just really want to avoid proliferation of "which handler should I create" code.
Additional context
As well as HttpVersion and HttpVersionPolicy as in #2404, the other aspect we'd like to see exposed is keep-alive (as per SocketsHttpHandler.KeepAlivePolicy etc)
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Both #2404 and internal issues I've been looking at for Google Cloud client libraries have required customization of the
HttpMessageHandler
used by gRPC.GrpcChannelOptions
provides theHttpClient
property which allows a caller to take complete control of the client used... but in our case we really just want to tweak some options, without having to reproduce all the code present in this repo to work out which handler to create in what situations.Describe the solution you'd like
A couple of options spring to mind:
GrpcChannelOptions
, and use those to automatically populate properties on anyHttpMessageHandler
constructed by gRPCAction<HttpMessageHandler> ConfigureMessageHandler
callback onGrcpChannelOptions
, which we'd probably want to call on each individualHttpMessageHandler
constructed (so if there's a chain of them, the callback doesn't have to walk the chain). Callers would then need to know how to configure multiple different types of handler, but it does provide complete flexibility.Potentially both options could be implemented.
Describe alternatives you've considered
I haven't had any better ideas than the ones above, but I'm certainly not wedded to those - if there are better options, that's great. I just really want to avoid proliferation of "which handler should I create" code.
Additional context
As well as
HttpVersion
andHttpVersionPolicy
as in #2404, the other aspect we'd like to see exposed is keep-alive (as perSocketsHttpHandler.KeepAlivePolicy
etc)The text was updated successfully, but these errors were encountered: