-
Notifications
You must be signed in to change notification settings - Fork 848
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
💡feat: allow for simpler override of Response header encoding of Forwarded Requests #2254
💡feat: allow for simpler override of Response header encoding of Forwarded Requests #2254
Conversation
…ResponseHeaderEncoding appropriately
resolves #1346 |
I'll suss out the license agreement soon once I figure out what exact company name to use wiht my employer. |
…ttpClientConfig.ResponseHeaderEncoding appropriately
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change looks good, thanks.
I don't really mind exposing the option given we have a corresponding setting for request headers already, but I question the usefulness of having it in the config given that Kestrel uses a different default for response headers, forcing you into making code changes anyway.
@microsoft-github-policy-service agree company="PageUpPeople" |
…server (with e.g. Kestrel) options for header encoding to match SocketsHttpHandler's header encoding options
Overview
This change intends to allow consumers to be able to choose tolerance for non-default (non-ASCII) encoding of Response headers for forwarded requests by leveraging
SocketsHttpHandler.ResponseHeaderEncodingSelector
. The idea is to provide something similar to the existingHttpClientConfig.RequestHeaderEncoding
property via a newHttpClientConfig.ResponseHeaderEncoding
property.Hopefully, this helps close #1346 and helps simplify solution for #2076.
Changes
SocketsHttpHandler.ResponseHeaderEncodingSelector
via newResponseHeaderEncoding
member inHttpClientConfig
ForwarderHttpClientFactory.ConfigureHandler
Testing
No additional testing has been performed other than relying on CI to validate updated & newly added tests in code. Happy to discuss more testing if required.