[jira] [Resolved] (THRIFT-5239) THttpTransport should support passing in an HttpClient

["Jens Geyer (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-5239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jens Geyer resolved THRIFT-5239.
--------------------------------
    Fix Version/s: 0.14.0
       Resolution: Fixed

> THttpTransport should support passing in an HttpClient
> ------------------------------------------------------
>
>                 Key: THRIFT-5239
>                 URL: https://issues.apache.org/jira/browse/THRIFT-5239
>             Project: Thrift
>          Issue Type: Bug
>          Components: netstd - Library
>            Reporter: Lewis Jackson
>            Assignee: Lewis Jackson
>            Priority: Major
>             Fix For: 0.14.0
>
>
> This issue is very similar to the Java one documented here: https://issues.apache.org/jira/browse/THRIFT-970
> .NET Core supports using an _[IHttpClientFactory|https://docs.microsoft.com/en-us/aspnet/core/fundamentals/http-requests?view=aspnetcore-3.1]_ to request instances of HttpClient. This factory will pool clients to avoid exhausting sockets in the OS. Microsoft currently do not recommend creating a new _HttpClient_ per request, consumers currently have to find a way to pool Thrift clients in order to conform to this practice.
> The line which instantiates a new _HttpClient_ can be found [here|https://github.com/apache/thrift/blob/283410126ccb3ac4990045e07cccb5df11ee2a16/lib/netstd/Thrift/Transport/Client/THttpTransport.cs#L141].
> This proposal would require a new constructor which allowed an instance of _HttpClient_ to be passed in. The consumer could use this constructor like this:
> {code:c#}
> var httpClientFactory = serviceProvider.GetService<IHttpClientFactory>();
> var httpClient = httpClientFactory.CreateClient("thrift");
> var transport = new THttpTransport(httpClient);
> {code}
> After registering their own named _IHttpClientFactory_ in the _ServiceCollection_:
> {code:c#}
> var certificates = GetCertificates();
> services.AddHttpClient("thrift", c =>
> {
>     c.BaseAddress = new Uri("https://foo.bar/Service.thrift");
>     c.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/x-thrift"));
>     c.DefaultRequestHeaders.AcceptEncoding.Add(new StringWithQualityHeaderValue("deflate"));
>     c.DefaultRequestHeaders.AcceptEncoding.Add(new StringWithQualityHeaderValue("gzip"));
>     c.DefaultRequestHeaders.Add("CUSTOM-HEADER", "HEADER-VALUE");
> })
>   .ConfigurePrimaryHttpMessageHandler(() =>
>   {
>       var handler = new HttpClientHandler()
>       {
>           AutomaticDecompression = System.Net.DecompressionMethods.Deflate | System.Net.DecompressionMethods.GZip
>       };
>       handler.ClientCertificates.AddRange(certificates);
>       return handler;
>   });
> {code}
> Rather than relying on users to properly configure request headers and decompression methods themselves, an extension method to _ServiceCollection_ could be defined:
> {code:c#}
> services.AddThriftHttpClient("thrift", uri, customRequestHeaders, userAgent, certificates);
> {code}
> This would more closely match the current constructor of _THttpTransport_.
> We've forked the _THttpTransport_ file to support this behaviour for internal purposes, so I could put up a sample PR if requested.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)