-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Implement Header encoding selectors on SocketsHttpHandler #39468
Merged
MihaZupan
merged 15 commits into
dotnet:master
from
MihaZupan:header-encoding-socketshttp
Jul 30, 2020
Merged
Changes from 1 commit
Commits
Show all changes
15 commits
Select commit
Hold shift + click to select a range
22ca8bb
Expose HeaderEncodingSelectors on SocketsHttpHandler
MihaZupan 2c425e4
Implement header encoding selectors in SocketsHttpHandler
MihaZupan 17b43ec
Add header encoding tests
MihaZupan 43b8caf
Add summaries for new APIs
MihaZupan 5a13ba0
Use Stream.Write(byte[], int, int) overloads for framework compat
MihaZupan 202268f
Add dummy API implementation to browser target
MihaZupan 6c6a078
Merge branch 'master' into header-encoding-socketshttp
MihaZupan 5aeaf40
HPack/QPack fixes
MihaZupan 7a44c28
Move HeaderEncodingSelector delegate to namespace, add TContext
MihaZupan be0dcdd
Encoding fixes
MihaZupan c171683
Remove unused using
MihaZupan 9b4fb5d
Merge master
MihaZupan 23c1d61
Simplify test
MihaZupan 5cc1ddd
HttpConnection PR feedback
MihaZupan 4e248e4
Simplify fast-path detection
MihaZupan File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next
Next commit
Expose HeaderEncodingSelectors on SocketsHttpHandler
- Loading branch information
commit 22ca8bbec057e4a1feb12d4276517ad74b4e5cc6
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
@Tratcher What do you think about switching Kestrel's RequestHeaderEncodingSelector to be a
delegate System.Text.Encoding? HeaderEncodingSelector(string headerName)
delegate?It would be a new delegate type most likely defined in the Microsoft.AspNetCore.Server.Kestrel namespace since we don't have an HttpRequestMessage or really anything comparable in the early stages of request parsing. Having the same name as the System.Net.Http delegate might be too confusing though.
I originally went with
Func<string, Encoding?>
(that's at least what it will be once we support nullable reference types in that assembly) because we don't use delegates very much in configuration callbacks in ASP.NET Core. Thinking about it more though, that's because normally the argument is a specific options or context type. Since the argument is just a string, naming it feels more worthwhile. Increased consistency with System.Net.Http is an added bonus.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.
It would be a small usability improvement.
I'd avoid using the same name though, that gets awkward when you import both namespaces.