Open sstere opened 3 months ago
Mentioning @nadeem-cs, @cs-raj and @uttamukkoji
Hi @sstere we have created ticket for the same, and we will be handling in upcoming sprints
@cs-raj Please also check issue #18 is indeed fixed. When I used ContentstackClient as Singleton I had same problem with that exception even if I upgraded to the latest version that contains the fix (0.1.8). I've seen now that is 0.1.10.
Is "Request Header Fields Too Large" really fixed now?
@cs-raj @nadeem-cs This client SDK is used by a big customer of Contentstack and I preferred to signal the issues in a public way and not go through the paid corporate support channel.
I hope you guys improve the quality of this library and make it more reliable.
Hi! Can you support IHttpClientFactory as described in here?
If I register the ContentstackClient as a Singleton I will have a long lived internal HttpClient that is created inside your ContentstackClient. It would be nice if this internal HttpClient can be passed from an IHttpClientFactory that handles the automatic "refresh" of HttpClientHandler and therefore addressing the DNS changes problem as quoted from the article in the link.
"Another issue that developers run into is when using a shared instance of HttpClient in long-running processes. In a situation where the HttpClient is instantiated as a singleton or a static object, it fails to handle the DNS changes as described in this issue of the dotnet/runtime GitHub repository."
@nadeem-cs @cs-raj You can make ContentstackClient receive HttpClient as constructor parameter and on a static extension method from some static class you could have something as:
Then I could just call services.AddContentstackClientService() in my startup and inject ContentstackClient wherever I need it knowing that the HttpClient is now managed by the IHttpClientFactory.
What do you think?
Thanks!