-
Notifications
You must be signed in to change notification settings - Fork 496
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
Make HTTP components configurable #605
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
d5751b3
Add HTTP factory options to SteamConfiguration
yaakov-h 123d0e2
Use HttpClient factory methods where possible
yaakov-h 3b8d105
Expose new methods in configuration builder
yaakov-h 24f963b
Add tests for new SteamConfiguration behaviour
yaakov-h d494c82
Remove stray blank line
yaakov-h 35ec168
This should fix the test on Linux...
yaakov-h 65279cc
Remove HttpMessageHandler extensibility point.
yaakov-h e2d6f88
Missed a spot
yaakov-h 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
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
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
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.
Won't this cause issues if consumer is using HttpClient for his own requests with custom base address (or lack of it)?
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 consumer shouldn’t be doing that. They can share an underlying HttpMessageHandler, but shouldn’t be sharing the HttpClient itself.
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's probably good idea to mention it then, I'd expect from SK2 to use my HttpClient as it is, without modifying its properties such as the base address.
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.
I would agree here, It should be easy enough to just pass base address into
urlBuilder
directly instead of usingHttpClient.BaseAddress
.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 xmldoc calls this out by differentiating between “returns a new or existing XXXXX” and “creates a new XXXXX”.
Sharing an http client outside of our own library would drastically limit how much of its functionality we can actually use, both now and into the future.
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.
This is a fair point, if you can see how it'd bite us in the future then I see no need to do any of that. In fact, I'd even vouch for complete removal of custom
HttpClient
and leave handler only, but sadly there areHttpClient
settings that the consumer might want to supply, mainly default request headers for identification purposes.Maybe it could be a good idea to allow consumer to supply only its own
HttpClientHandler
and default headers, leaving creatingHttpClient
to SK2. I don't see any other reason for one to force usage of its ownHttpClient
, and because SK2 is expected to modify its properties anyway, doing it this way would avoid a lot of confusion (even if it's stated in the doc).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.
If the consumer wants to re-use
HttpMessageHandler
instances, then theHttpClient
has to be created withdispose: false
so that the handler is re-usable and not killed early.We could make a
bool ShouldDisposeOfHandler(HttpMessageHandler handler)
method, but that seems oddly specific.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 feels fine for me to supply message handler, default headers and value specifying that my handler is supposed to be reused in my own routines further, so it shouldn't be disposed.
Considering that there is really not much more to add towards that (I mean, you've defined everything regarding how to create and use
HttpClient
by now), I feel that it's a good tradeoff for having a guarantee thatHttpClient
created by SK2 has expected state and no issues as long as user can guarantee that his message handler is proper.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.
Still, this is more like a design choice over personal preferences rather than some crucial decision, so I leave that up to you, the PR is fine as it is, I just don't see a reason why consumer must create
HttpClient
and ensure it meets all SK2 requirements and can be modified, if SK2 can pretty much do the same with just 1 more argument (headers + disposing vs httpclient alone).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.
If the consumer:
Then they don't need to create a
HttpClient
. If they want more advanced control, then I'd rather give them more advanced control rather than re-invent the wheel.For example, they could use
HttpClientFactory
with few (if any) modifications.