-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Validate and cover HttpClient extensibility #40624
Comments
Tagging subscribers to this area: @dotnet/ncl |
@scalablecory @geoffkizer @stephentoub questions:
|
Correct |
I think all of these scenarios boil down to ensuring that the hooks we provide are actually working as intended. Specifically we should add some tests that |
I agree we should do such a general approach for good measure. But we also need to validate the specific scenarios we were targeting. Case in point, the UDS scenario that failed because the implementation was trying to disable nagle and that throws with a Unix Domain Socket wouldn't have been caught by the above plan. |
I agree; I think the question is how to do this. Does this mean unit tests? Sample code? What? I don't think we want/need to actually implement bandwidth monitoring in our unit tests, for example.
I agree, we should have a unit test for this. |
Re UDS: |
One important use case we'll be using this new abstraction for, is improving diagnostics when calling a remote peer that is actually a Load Balancer (e.g. Azure Load Balancer). What we're planning to do is call the remote service, remote.foo.com, connect to it, request a well-known url say /information, which gives us some diagnostics information, maybe a real IPv4/IPv6 or in a microservices world "InstanceId" and we attach to that to this connection object. Only after this piece of work is done we make this connection available for use. This is super useful, because when 100 HTTP requests later for whatever reason the http request fails, we can tell you what instance of the service we associated in that first connection. This information can then be provided to the service we were calling and they can debug further. |
That seems like a good thing for us to write a sample for, and validate that this works. @antonfirsov is this something you plan to tackle? |
I wrote a sample of an in memory transport and plugged it into HttpClient: |
@JamesNK has been working on a named pipes transport for gRPC. |
A follow-up on #40506 (comment).
In #1793 we identified 8 scenarios, which could be solved by using a custom
ConnectionFactory
inSocketsHttpHandler.ConnectionFactory
. Ideally the design enables them, however most of those scenarios are still not validated. We need end-to-end tests inSystem.Net.Http
to validate and cover these scenarios:The text was updated successfully, but these errors were encountered: