Skip to content
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

Provide HttpMessageHandler customization callbacks #2435

Open
jskeet opened this issue May 13, 2024 · 1 comment
Open

Provide HttpMessageHandler customization callbacks #2435

jskeet opened this issue May 13, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@jskeet
Copy link

jskeet commented May 13, 2024

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 individual HttpMessageHandler 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 jskeet added the enhancement New feature or request label May 13, 2024
@jskeet
Copy link
Author

jskeet commented May 13, 2024

cc @amanda-tarafa

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant