Search code examples
c#.net-corecompression

Is there any strong reason why to not always use DecompressionMethods.All?

I had an a de-compression issue with after mismatching between the Accept-Encoding value and the AutomaticDecompression value of the HttpClientHandler,

In this case, I was missing the | DecompressionMethods.Brotli on AutomaticDecompression after having an Accept-Encoding of , br:

services.AddHttpClient(E_HttpClient.Typicode.ToString(), client =>
{
    client.DefaultRequestHeaders.Add("Accept-Encoding", "gzip, br");
    //...
})
.ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
{
    AutomaticDecompression = DecompressionMethods.GZip
});

So I could resolve this issue by Option 1:

    AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Brotli

Or by option 2:

    AutomaticDecompression = DecompressionMethods.All

Is there any strong reason why not always keep the DecompressionMethods to All always as a best practice?

Solution

  • No, unless you're concerned about the (usually negligible) increase in CPU for decompressing.

    There is also no guesswork happening on the client, you send the compression methods you support with Accept-Encoding, and the server selects the most suitable one and includes it in the response header Content-Encoding.

    If low latency is prioritized, using compression is usually faster than not. At least if you trust the server to have a suitable compression based on a normal message size.

    Note that HttpClient has no compression enabled as default, so it's good practice to set it.