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)
jskeet
commented
1 month ago
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
HttpMessageHandlerused by gRPC.GrpcChannelOptionsprovides theHttpClientproperty 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 anyHttpMessageHandlerconstructed by gRPCAction<HttpMessageHandler> ConfigureMessageHandlercallback onGrcpChannelOptions, which we'd probably want to call on each individualHttpMessageHandlerconstructed (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
HttpVersionandHttpVersionPolicyas in #2404, the other aspect we'd like to see exposed is keep-alive (as perSocketsHttpHandler.KeepAlivePolicyetc)