c# - 是否有任何强有力的理由为什么不总是使用 DecompressionMethods.All?

标签 c# .net-core compression

Accept-Encoding 值与 HttpClientHandlerAutomaticDecompression 值不匹配后,我遇到了解压缩问题,

在这种情况下,我缺少 |在 Accept-Encoding、br 后,在 AutomaticDecompression 上 DecompressionMethods.Brotli:

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

所以我可以通过选项 1 解决这个问题:

    AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Brotli

或者通过选项 2:

    AutomaticDecompression = DecompressionMethods.All

是否有任何强有力的理由为什么不始终将 DecompressionMethods 保留为 All 始终 作为最佳实践?

最佳答案

不,除非您担心解压缩时 CPU 的增加(通常可以忽略不计)。

客户端上也不会发生猜测,您通过 Accept-Encoding 发送您支持的压缩方法,服务器会选择最合适的一种并将其包含在响应 header Content-Encoding 中。

如果优先考虑低延迟,则使用压缩通常比不使用压缩更快。至少如果您相信服务器会根据正常消息大小进行适当的压缩。

请注意,HttpClient 默认情况下未启用压缩,因此最好使用 set it .

关于c# - 是否有任何强有力的理由为什么不总是使用 DecompressionMethods.All?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/65754499/

相关文章:

.net - 在 .NET 核心中查找 2 个坐标之间的距离

.net-core - dotnet 核心 2.1 : "Found conflicts between different versions of" when referencing a web project from an xunit project

javascript - 使用 'self' 或 'this' 进行 JavaScript 缩小是否更紧凑?

android - 如何压缩sqlite数据库

c# - 使用 Visual C# 2008 Express 开发 Outlook 插件?

c# - 如何检查密码重置 token 是否已过期?

c# - 自定义 JSON 派生格式

c# - 将 Prebuild 或 Postbuild 添加到 dotnet 核心项目

javascript - 防止闭包编译器重命名某些变量

c# - JQuery MVC3 内联 Jquery 代码