Conversation
|
Tagging subscribers to this area: @karelz, @dotnet/ncl |
There was a problem hiding this comment.
Pull request overview
This PR adds a small explanatory comment to HttpMessageInvoker.cs to document why the _handler field should remain private.
Changes:
- Adds a two-line comment above the
_handlerfield explaining the rationale for keeping it private
| @@ -11,6 +11,8 @@ public class HttpMessageInvoker : IDisposable | |||
| { | |||
| private volatile bool _disposed; | |||
| private readonly bool _disposeHandler; | |||
| // Do not make the _handler field public. | |||
| // Exposing it might interfere with HttpClientFactory handler recycling behavior. | |||
There was a problem hiding this comment.
I don't understand this comment.
a) We would never make _handler public for .NET API design reasons.
b) It's unclear how exposing the additional information (e.g. as a get-only property) would interfere with recycling behavior.
There was a problem hiding this comment.
If the user has access to the instance, they could then keep it alive longer than the client (by storing it somewhere) and that would break the recycling logic in HCF. This was one of the recommendations coming out of a discussion about HCF Threat Model.
There was a problem hiding this comment.
This is about GC lifetime? The HttpMessageInvoker itself stores a reference to it. If the user is holding on to the HttpMessageInvoker, they're holding on to the handler indirectly. Moreover, to construct HttpMessageInvoker requires passing the handler into the ctor, so whoever constructed the HttpMessageInvoker could still be holding a direct reference to the instance.
No description provided.