Compressão de resposta no ASP.NET Core

A largura de banda da rede é um recurso limitado. Reduzir o tamanho da resposta geralmente aumenta a capacidade de resposta de um aplicativo, muitas vezes dramaticamente. Uma forma de reduzir o tamanho da carga útil é comprimir as respostas de uma aplicação. Este artigo descreve como implementar compressão de resposta para as suas aplicações utilizando middleware de compressão de resposta no ASP.NET Core.

Explore a compressão com HTTPS

Respostas compactadas em conexões seguras podem ser controladas com a opção EnableForHttps, que é desabilitada por padrão devido ao risco de segurança. O uso da compactação com páginas geradas dinamicamente pode expor o aplicativo a ataques CRIME e ataques BREACH. Ataques como CRIME e BREACH podem ser mitigados no ASP.NET Core com tokens antifalsificação. Para obter mais informações, consulte Impedir ataques de falsificação de solicitação entre sites (XSRF/CSRF) no ASP.NET Core. Para informações sobre mitigação BREACH de ataques, veja Mitigações em http://www.breachattack.com/.

Mesmo quando a aplicação desativa a propriedade EnableForHttps (false), Serviços de Informação Internet (IIS), IIS Express e Serviço de Aplicações do Azure podem aplicar-se Gzip no servidor web IIS. Quando rever os cabeçalhos de resposta, note o valor do cabeçalho do servidor . Um valor inesperado de cabeçalho de resposta content-encoding pode ser resultado do servidor web e não da configuração da aplicação ASP.NET Core.

Determinar quando usar middleware de compressão de resposta

Use tecnologias de compactação de resposta baseadas em servidor no IIS, Apache ou Nginx. O desempenho do middleware de compressão de resposta provavelmente não consegue igualar o dos módulos de servidor. O servidor HTTP.sys e o Kestrel servidor não oferecem atualmente suporte incorporado à compressão.

Utilize o middleware de compressão de resposta quando a aplicação se encontra:

• Incapaz de utilizar as seguintes tecnologias de compressão baseadas em servidor:

  • Cache e compressão dinâmicas do IIS
  • Módulo Apache mod_deflate
  • Compressão e descompressão Nginx

• Hospedar diretamente em:

  • HTTP.sys servidor
  • Kestrel servidor

Explorar a compressão de resposta

Normalmente, qualquer resposta não compactada nativamente pode se beneficiar da compressão de resposta. As respostas não compactadas nativamente normalmente incluem CSS, JavaScript, HTML, XML e JSON. Não compacte ativos compactados nativamente, como arquivos PNG. Ao tentar comprimir ainda mais uma resposta comprimida nativamente, qualquer pequena redução extra no tamanho e no tempo de transmissão provavelmente é ofuscada pelo tempo que demora a processar a compressão. Não comprimas ficheiros com menos de 150 - 1.000 bytes, dependendo do conteúdo do ficheiro e da eficiência da compressão. A sobrecarga de comprimir ficheiros pequenos pode produzir um ficheiro comprimido maior do que o ficheiro não comprimido.

Quando um cliente pode processar conteúdo comprimido, o cliente deve informar o servidor das suas capacidades enviando o cabeçalho Accept-Encoding com o pedido. Quando um servidor envia conteúdo comprimido, deve incluir informação no cabeçalho Content-Encoding sobre como a resposta comprimida é codificada.

A tabela seguinte mostra as designações de codificação de conteúdo para o Accept-Encoding cabeçalho e indica se o middleware de compressão de resposta suporta a designação.

Para mais informações, consulte a Lista Oficial de Codificação de Conteúdo da IANA para parâmetros HTTP.

O middleware de compressão de resposta permite adicionar fornecedores adicionais de compressão para valores de cabeçalho personalizados Accept-Encoding. Para mais informações, consulte Fornecedores Personalizados mais adiante neste artigo.

O middleware de compressão de resposta é capaz de reagir à ponderação do valor de qualidade (qvalue, q) quando enviado pelo cliente para priorizar esquemas de compactação. Para mais informações, consulte RFC 9110: Semântica HTTP (Secção 12.5.3 Accept-Encoding).

Os algoritmos de compressão estão sujeitos a um equilíbrio entre a velocidade de compressão e a eficácia da compressão. A eficácia neste contexto refere-se ao tamanho da saída após a compressão. O menor tamanho é alcançado pela compressão ideal.

Os cabeçalhos envolvidos na solicitação, envio, armazenamento em cache e recebimento de conteúdo compactado são descritos na tabela a seguir.

Explore as funcionalidades do middleware de compressão de respostas com a aplicação de exemplo. A amostra ilustra:

• Compressão das respostas da aplicação através do uso de Gzip e fornecedores de compressão personalizados.
• Como adicionar um tipo MIME à lista padrão de tipos MIME para compactação.
• Como adicionar um provedor de compactação de resposta personalizado.

Configurar o middleware de compressão de resposta

O código seguinte mostra como ativar o middleware de compressão de resposta para os tipos MIME e os fornecedores de compressão predefinidos (Brotli e Gzip):

O código seguinte mostra como ativar o middleware de compressão de resposta para tipos MIME e fornecedores de compressão padrão (Brotli, Gzip e Zstandard):

Notas sobre o middleware de compressão de respostas

Quando trabalhas com middleware de compressão de resposta, lembra-te dos seguintes pontos:

• Definir a EnableForHttps propriedade para true é um risco de segurança. Para mais informações, consulte a secção Compressão com HTTPS mais cedo neste artigo.
• O método app.UseResponseCompression deve ser chamado antes de qualquer middleware que comprima as respostas. Para mais informações, veja ASP.NET Core > middleware Middleware order.
• Utilize uma ferramenta como Firefox Browser - Developer edition para definir o Accept-Encoding cabeçalho do pedido e examinar os cabeçalhos da resposta, o tamanho e o corpo.

Envie uma solicitação para o aplicativo de exemplo sem o Accept-Encoding cabeçalho e observe que a resposta está descompactada. O Content-Encoding cabeçalho não está na coleção Cabeçalhos de Resposta.

Por exemplo, no Firefox Developer:

1. Selecione a aba Rede.
2. Clique com o botão direito no pedido na lista de pedidos de Rede e selecione Editar e reenviar.
3. Altere o Accept-Encoding: valor de gzip, deflate, br para none.
4. Selecione Enviar.

Submeta um pedido à aplicação de exemplo através de um navegador usando as ferramentas de desenvolvimento e observe que a resposta está comprimida. Os cabeçalhos Content-Encoding e Vary estão presentes na resposta.

Analisar fornecedores

Esta secção fornece detalhes sobre fornecedores de compressão, incluindo Brotli, Gzip e fornecedores personalizados.

Esta secção fornece detalhes sobre fornecedores de compressão, incluindo Brotli, Gzip, Zstandard e fornecedores personalizados.

Provedores de compressão Brotli e Gzip

Utilize a BrotliCompressionProvider class para comprimir respostas com o RFC 7932: Formato de Dados Comprimidos Brotli.

Se não forem explicitamente adicionados fornecedores de compressão à CompressionProviderCollection classe:

• Por defeito, os fornecedores de compressão Brotli e Gzip são adicionados à lista de fornecedores de compressão.
• Quando o cliente suporta o formato de dados comprimido Brotli, a compressão padrão passa a ser a Brotli.
• Se o cliente não suportar Brotli, a compressão será automaticamente Gzip quando o cliente suportar compressão Gzip.

• Por predefinição, os provedores de compressão Brotli, Gzip e Zstandard são adicionados à matriz de provedores de compressão.
• Quando o cliente é compatível com o formato de dados comprimidos Zstandard, a compressão Zstandard é utilizada por predefinição.
• Se o cliente não suportar Zstandard, mas suportar Brotli, é utilizada, por predefinição, a compressão Brotli.
• Se o cliente não suportar Zstandard nem Brotli, a compressão é definida por predefinição como Gzip, desde que o cliente suporte compressão Gzip.

Quando um provedor de compactação é adicionado, outros provedores não são adicionados. Por exemplo, se o provedor de compactação Gzip for o único provedor explicitamente adicionado, nenhum outro provedor de compactação será adicionado.

O seguinte código:

• Permite a compactação de resposta para solicitações HTTPS.
• Adiciona os provedores de compressão de resposta Brotli e Gzip.

using System.IO.Compression;
using Microsoft.AspNetCore.ResponseCompression;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
    options.Providers.Add<BrotliCompressionProvider>();
    options.Providers.Add<GzipCompressionProvider>();
});

builder.Services.Configure<BrotliCompressionProviderOptions>(options =>
{
    options.Level = CompressionLevel.Fastest;
});

builder.Services.Configure<GzipCompressionProviderOptions>(options =>
{
    options.Level = CompressionLevel.SmallestSize;
});

var app = builder.Build();

app.UseResponseCompression();

app.MapGet("/", () => "Hello World!");

app.Run();

Defina o nível de compressão com a classe BrotliCompressionProviderOptions e a classe GzipCompressionProviderOptions. Os fornecedores de compressão Brotli e Gzip, por defeito, utilizam o nível de compressão mais rápido, conforme determinado pelo enum CompressionLevel.Fastest. No entanto, esta abordagem pode não produzir a compressão mais eficiente. Se a compactação mais eficiente for desejada, configure o middleware de compactação de resposta para uma compactação ideal.

Para valores que indicam se uma operação de compressão enfatiza a velocidade ou o tamanho da compressão, veja o CompressionLevel Enum.

using System.IO.Compression;
using Microsoft.AspNetCore.ResponseCompression;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
    options.Providers.Add<BrotliCompressionProvider>();
    options.Providers.Add<GzipCompressionProvider>();
});

builder.Services.Configure<BrotliCompressionProviderOptions>(options =>
{
    options.Level = CompressionLevel.Fastest;
});

builder.Services.Configure<GzipCompressionProviderOptions>(options =>
{
    options.Level = CompressionLevel.SmallestSize;
});

var app = builder.Build();

app.UseResponseCompression();

app.MapGet("/", () => "Hello World!");

app.Run();

Fornecedor de compressão Zstandard

Use a classe ZstandardCompressionProvider para comprimir respostas com a RFC 8878: Compressão Zstandard para HTTP.

Define a qualidade da compressão com a ZstandardCompressionProviderOptions classe. O nível de qualidade Zstandard varia de 1 a 22, onde valores mais elevados produzem melhor compressão mas velocidades mais lentas. O exemplo seguinte define a qualidade de compressão Zstandard:

builder.Services.Configure<ZstandardCompressionProviderOptions>(options =>
{
    options.CompressionOptions = new ZstandardCompressionOptions
    {
        Quality = 6 // 1 to 22, higher = better compression, slower
    };
});

Fornecedores personalizados

Crie implementações personalizadas de compressão com a ICompressionProvider interface. A EncodingName propriedade representa a codificação de conteúdo que isto ICompressionProvider produz. O middleware de compactação de resposta usa essas informações para escolher o provedor com base na lista especificada no Accept-Encoding cabeçalho da solicitação.

As solicitações para o aplicativo de exemplo com o Accept-Encoding: mycustomcompression cabeçalho retornam uma resposta com um Content-Encoding: mycustomcompression cabeçalho. O cliente deve ser capaz de descompactar a codificação personalizada para que uma implementação de compactação personalizada funcione.

using Microsoft.AspNetCore.ResponseCompression;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression(options =>
{
    options.Providers.Add<BrotliCompressionProvider>();
    options.Providers.Add<GzipCompressionProvider>();
    options.Providers.Add<CustomCompressionProvider>();
});

var app = builder.Build();

app.UseResponseCompression();

app.MapGet("/", () => "Hello World!");

app.Run();

using Microsoft.AspNetCore.ResponseCompression;

public class CustomCompressionProvider : ICompressionProvider
{
    public string EncodingName => "mycustomcompression";
    public bool SupportsFlush => true;

    public Stream CreateStream(Stream outputStream)
    {
        // Replace with a custom compression stream wrapper.
        return outputStream;
    }
}

No código anterior, o exemplo não comprime o corpo da resposta. No entanto, o exemplo mostra onde implementar um algoritmo de compactação personalizado.

Revise os tipos MIME

O middleware de compressão de resposta especifica um conjunto padrão de tipos MIME para compactação. Consulte o código-fonte para uma lista completa dos tipos MIME suportados.

Substitua ou adicione tipos MIME com a propriedade ResponseCompressionOptions.MimeTypes . Tipos MIME coringa, como text/*, não são suportados. O aplicativo de exemplo adiciona um tipo MIME para image/svg+xml , compacta e serve a imagem de banner ASP.NET Core banner.svg.

using Microsoft.AspNetCore.ResponseCompression;
using ResponseCompressionSample;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
    options.Providers.Add<BrotliCompressionProvider>();
    options.Providers.Add<GzipCompressionProvider>();
    options.Providers.Add<CustomCompressionProvider>();
    options.MimeTypes =
    ResponseCompressionDefaults.MimeTypes.Concat(
        new[] { "image/svg+xml" });
});

var app = builder.Build();

app.UseResponseCompression();

Adicione o cabeçalho Vary

Quando as respostas são comprimidas com base no cabeçalho de pedido Accept-Encoding, pode haver versões da resposta tanto comprimidas quanto não comprimidas. Para instruir as memórias cache cliente e proxy de que existem múltiplas versões e devem ser armazenadas, o cabeçalho Vary é adicionado com o valor Accept-Encoding. O middleware de resposta adiciona automaticamente o cabeçalho 'Vary' no ficheiro ResponseCompressionBody.cs quando a resposta é comprimida.

Problemas com o proxy reverso Nginx

Quando o Nginx atua como proxy do pedido, o cabeçalho Accept-Encoding é removido. A remoção do cabeçalho Accept-Encoding impede que o middleware de compressão da resposta comprima a resposta. Para mais informações, veja Nginx: Compressão e descompressão. Este problema é acompanhado no GitHub dotnet/aspnetcore issue #5989 - Resolver a compressão pass-through para Nginx.

Desativar a compressão dinâmica do IIS

Para desabilitar o Módulo de Compactação Dinâmica do IIS configurado no nível do servidor, consulte Desabilitando módulos do IIS.

Solucionar problemas de compactação de resposta

Usa uma ferramenta como o Firefox Browser - Developer Edition que te permite definir o Accept-Encoding cabeçalho do pedido e estudar os cabeçalhos da resposta, o tamanho e o corpo. Por defeito, o middleware de compressão de respostas comprime respostas que cumprem as seguintes condições:

• O Accept-Encoding cabeçalho está presente com um valor de br, gzip, * (asterisco), ou codificação personalizada que corresponde a um fornecedor de compressão personalizado. O valor não deve ser identity (sem codificação) nem ter um valor de qualidade (valor q, q) definido 0 (zero).

• O Accept-Encoding cabeçalho está presente com um valor de br, gzip, zstd, * (asterisco), ou codificação personalizada que corresponde a um fornecedor de compressão personalizado. O valor não deve ser identity (sem codificação) nem ter um valor de qualidade (valor q, q) definido 0 (zero).

• O tipo MIME (Content-Type) deve ser definido e deve corresponder a um tipo MIME configurado na ResponseCompressionOptions classe.

• O pedido não pode incluir o cabeçalho Content-Range.

• O pedido deve usar o protocolo de hipertexto inseguro (http), a menos que o protocolo de hipertexto seguro (https) esteja configurado nas opções de middleware de compressão de resposta.

  Importante

  Reveja os riscos associados à ativação da compressão segura de conteúdos, conforme descrito em Compressão com HTTPS anteriormente neste artigo.

Revise o exemplo implementado no Azure

A aplicação de exemplo implementada em Azure tem o seguinte ficheiro Program.cs:

using Microsoft.AspNetCore.ResponseCompression;
using ResponseCompressionSample;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
    options.Providers.Add<BrotliCompressionProvider>();
    options.Providers.Add<GzipCompressionProvider>();
    options.Providers.Add<CustomCompressionProvider>();
    options.MimeTypes =
    ResponseCompressionDefaults.MimeTypes.Concat(
        new[] { "image/svg+xml" });
});

var app = builder.Build();

app.UseResponseCompression();

app.Map("/trickle", async (HttpResponse httpResponse) =>
{
    httpResponse.ContentType = "text/plain;charset=utf-8";

    for (int i = 0; i < 20; i++)
    {
        await httpResponse.WriteAsync("a");
        await httpResponse.Body.FlushAsync();
        await Task.Delay(TimeSpan.FromMilliseconds(50));
    }
});

app.Map("/testfile1kb.txt", () => Results.File(
    app.Environment.ContentRootFileProvider.GetFileInfo("testfile1kb.txt").PhysicalPath,
    "text/plain;charset=utf-8"));

app.Map("/banner.svg", () => Results.File(
    app.Environment.ContentRootFileProvider.GetFileInfo("banner.svg").PhysicalPath,
    "image/svg+xml;charset=utf-8"));

app.MapFallback(() => LoremIpsum.Text);

app.Run();

Conteúdo relacionado

• Visualizar ou descarregar amostra de código (como descarregar)
• Origem do middleware de compressão de resposta
• RFC 9110: Semântica HTTP (Secção 8.4.1 Codificações de Conteúdo)
• RFC 9110: Semântica HTTP (Secção 8.4.1.3 Codificação Gzip)
• RFC 1952: Especificação do formato de ficheiro GZIP versão 4.3
• RFC 8878: Compressão Zstandard para HTTP

A largura de banda da rede é um recurso limitado. Reduzir o tamanho da resposta geralmente aumenta a capacidade de resposta de um aplicativo, muitas vezes dramaticamente. Uma maneira de reduzir o tamanho da carga útil é compactar as respostas de um aplicativo.

Visualizar ou descarregar amostra de código (como descarregar)

Quando usar middleware de compressão de resposta

Use tecnologias de compactação de resposta baseadas em servidor no IIS, Apache ou Nginx. O desempenho do middleware provavelmente não corresponderá ao dos módulos do servidor. HTTP.sys servidor e Kestrel servidor não oferecem atualmente suporte de compressão incorporado.

Utilize o middleware de compressão de respostas nos seguintes casos:

• Não é possível usar as seguintes tecnologias de compactação baseadas em servidor:
  • Módulo de compressão dinâmica do IIS
  • Módulo Apache mod_deflate
  • Compressão e Descompressão Nginx
• Hospedagem diretamente em:
  • HTTP.sys servidor (anteriormente chamado WebListener)
  • Kestrel servidor

Compressão de resposta

Normalmente, qualquer resposta não compactada nativamente pode se beneficiar da compressão de resposta. As respostas não compactadas nativamente normalmente incluem: CSS, JavaScript, HTML, XML e JSON. Você não deve compactar ativos compactados nativamente, como arquivos PNG. Se você tentar compactar ainda mais uma resposta compactada nativamente, qualquer pequena redução adicional no tamanho e no tempo de transmissão provavelmente será ofuscada pelo tempo necessário para processar a compressão. Não compacte arquivos menores que cerca de 150-1000 bytes (dependendo do conteúdo do arquivo e da eficiência da compactação). A sobrecarga de compactar arquivos pequenos pode produzir um arquivo compactado maior do que o arquivo não compactado.

Quando um cliente pode processar conteúdo compactado, o cliente deve informar o servidor de suas capacidades, enviando o Accept-Encoding cabeçalho com a solicitação. Quando um servidor envia conteúdo compactado, ele deve incluir informações no Content-Encoding cabeçalho sobre como a resposta compactada é codificada. As designações de codificação de conteúdo suportadas pelo middleware são mostradas na tabela a seguir.

Para obter mais informações, consulte a Lista de Codificação de Conteúdo Oficial da IANA.

O middleware permite adicionar provedores de compactação adicionais para valores de cabeçalho personalizados Accept-Encoding . Para obter mais informações, consulte Provedores personalizados abaixo.

O middleware tem a capacidade de reagir à ponderação do valor de qualidade (qvalue, q) enviada pelo cliente para priorizar os esquemas de compressão. Para obter mais informações, consulte RFC 9110: Accept-Encoding.

Os algoritmos de compressão estão sujeitos a um equilíbrio entre a velocidade de compressão e a eficácia da compressão. A eficácia neste contexto refere-se ao tamanho da saída após a compressão. O menor tamanho é alcançado pela compressão mais ideal .

Os cabeçalhos envolvidos na solicitação, envio, armazenamento em cache e recebimento de conteúdo compactado são descritos na tabela abaixo.

Explore as funcionalidades do middleware de compressão de respostas com a aplicação de exemplo. A amostra ilustra:

• A compactação de respostas de aplicações usando Gzip e fornecedores de compactação personalizados.
• Como adicionar um tipo MIME à lista padrão de tipos MIME para compactação.

Configuration

O código seguinte mostra como ativar o middleware de compressão de resposta para os tipos MIME predefinidos e os provedores de compressão (Brotli e Gzip):

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddResponseCompression();
    }

    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        app.UseResponseCompression();
    }
}

Notes:

• app.UseResponseCompression deve ser chamado antes de qualquer middleware que comprima respostas. Para mais informações, consulte middleware ASP.NET Core.
• Use uma ferramenta como Fiddler, Firefox Browser Developer para definir o cabeçalho da Accept-Encoding solicitação e estudar os cabeçalhos de resposta, tamanho e corpo.

Envie uma solicitação para o aplicativo de exemplo sem o Accept-Encoding cabeçalho e observe que a resposta está descompactada. Os cabeçalhos Content-Encoding e Vary não estão presentes na resposta.

Envie uma solicitação para o aplicativo de exemplo com o Accept-Encoding: br cabeçalho (compressão Brotli) e observe que a resposta está compactada. Os cabeçalhos Content-Encoding e Vary estão presentes na resposta.

Providers

Provedor de compressão Brotli

Use o BrotliCompressionProvider para compactar respostas com o formato de dados compactados Brotli.

Se nenhum provedor de compressão for explicitamente adicionado ao CompressionProviderCollection:

• O Provedor de Compactação Brotli é adicionado por padrão à matriz de provedores de compactação junto com o provedor de compactação Gzip.
• A compressão predefinida é Brotli quando o formato de dados comprimidos Brotli é suportado pelo cliente. Se a compressão Brotli não for suportada pelo cliente, a compressão padrão será Gzip quando o cliente suportar a compressão Gzip.

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();
}

O Provedor de Compactação Brotli deve ser adicionado quando qualquer provedor de compactação é explicitamente adicionado:

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression(options =>
    {
        options.Providers.Add<BrotliCompressionProvider>();
        options.Providers.Add<GzipCompressionProvider>();
        options.Providers.Add<CustomCompressionProvider>();
        options.MimeTypes = 
            ResponseCompressionDefaults.MimeTypes.Concat(
                new[] { "image/svg+xml" });
    });
}

Defina o nível de compressão com BrotliCompressionProviderOptions. O Brotli Compression Provider usa como padrão o nível de compactação mais rápido (CompressionLevel.Fastest), que pode não produzir a compactação mais eficiente. Se a compactação mais eficiente for desejada, configure o middleware para uma compactação ideal.

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();

    services.Configure<BrotliCompressionProviderOptions>(options => 
    {
        options.Level = CompressionLevel.Fastest;
    });
}

Provedor de compressão Gzip

Use o GzipCompressionProvider para compactar respostas com o formato de arquivo Gzip.

Se nenhum provedor de compressão for explicitamente adicionado ao CompressionProviderCollection:

• O Provedor de Compactação Gzip é adicionado por padrão à matriz de provedores de compactação junto com o Provedor de Compactação Brotli.
• A compressão predefinida é Brotli quando o formato de dados comprimidos Brotli é suportado pelo cliente. Se a compressão Brotli não for suportada pelo cliente, a compressão padrão será Gzip quando o cliente suportar a compressão Gzip.

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();
}

O Provedor de Compactação Gzip deve ser adicionado quando qualquer provedor de compactação for explicitamente adicionado:

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression(options =>
    {
        options.Providers.Add<BrotliCompressionProvider>();
        options.Providers.Add<GzipCompressionProvider>();
        options.Providers.Add<CustomCompressionProvider>();
        options.MimeTypes = 
            ResponseCompressionDefaults.MimeTypes.Concat(
                new[] { "image/svg+xml" });
    });
}

Defina o nível de compressão com GzipCompressionProviderOptions. O Provedor de Compressão Gzip assume como padrão o nível de compactação mais rápido (CompressionLevel.Fastest), que pode não produzir a compactação mais eficiente. Se a compactação mais eficiente for desejada, configure o middleware para uma compactação ideal.

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();

    services.Configure<GzipCompressionProviderOptions>(options => 
    {
        options.Level = CompressionLevel.Fastest;
    });
}

Fornecedores personalizados

Crie implementações de compressão personalizadas com ICompressionProvider. O EncodingName representa a codificação de conteúdo que isso ICompressionProvider produz. O middleware usa essas informações para escolher o provedor com base na lista especificada no Accept-Encoding cabeçalho da solicitação.

Usando o aplicativo de exemplo, o cliente envia uma solicitação com o Accept-Encoding: mycustomcompression cabeçalho. O middleware usa a implementação de compactação personalizada e retorna a resposta com um Content-Encoding: mycustomcompression cabeçalho. O cliente deve ser capaz de descompactar a codificação personalizada para que uma implementação de compactação personalizada funcione.

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression(options =>
    {
        options.Providers.Add<BrotliCompressionProvider>();
        options.Providers.Add<GzipCompressionProvider>();
        options.Providers.Add<CustomCompressionProvider>();
        options.MimeTypes = 
            ResponseCompressionDefaults.MimeTypes.Concat(
                new[] { "image/svg+xml" });
    });
}

public class CustomCompressionProvider : ICompressionProvider
{
    public string EncodingName => "mycustomcompression";
    public bool SupportsFlush => true;

    public Stream CreateStream(Stream outputStream)
    {
        // Create a custom compression stream wrapper here
        return outputStream;
    }
}

Envie uma solicitação para o aplicativo de exemplo com o Accept-Encoding: mycustomcompression cabeçalho e observe os cabeçalhos de resposta. Os cabeçalhos Vary e Content-Encoding estão presentes na resposta. O corpo da resposta (não mostrado) não é comprimido pela amostra. Não há uma implementação de compactação na CustomCompressionProvider classe do exemplo. No entanto, o exemplo mostra onde você implementaria esse algoritmo de compactação.

Tipos MIME

O middleware especifica um conjunto padrão de tipos MIME para compactação:

• application/javascript
• application/json
• application/xml
• text/css
• text/html
• text/json
• text/plain
• text/xml

Substitua ou adicione tipos MIME através das opções do middleware de compressão da resposta. Note que os tipos MIME curinga, como text/*, não são suportados. O aplicativo de exemplo adiciona um tipo MIME para o image/svg+xml, compacta e serve a imagem do banner do ASP.NET Core (banner.svg).

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression(options =>
    {
        options.Providers.Add<BrotliCompressionProvider>();
        options.Providers.Add<GzipCompressionProvider>();
        options.Providers.Add<CustomCompressionProvider>();
        options.MimeTypes = 
            ResponseCompressionDefaults.MimeTypes.Concat(
                new[] { "image/svg+xml" });
    });
}

Compressão com protocolo seguro

As respostas comprimidas através de ligações seguras podem ser controladas com a opção EnableForHttps, que está desativada por predefinição. Usar a compactação com páginas geradas dinamicamente pode levar a problemas de segurança, como os ataques CRIME e BREACH.

Adicione o cabeçalho Vary

Ao compactar respostas com base no Accept-Encoding cabeçalho, há potencialmente várias versões compactadas da resposta e uma versão não compactada. Para instruir os caches de cliente e de proxy de que existem várias versões e devem ser armazenadas, é adicionado o cabeçalho Vary com um valor Accept-Encoding. No ASP.NET Core 2.0 ou posterior, o middleware adiciona o cabeçalho Vary automaticamente quando a resposta é compactada.

Problema de middleware quando atrás de um proxy reverso Nginx

Quando uma solicitação é encaminhada pelo Nginx, o cabeçalho Accept-Encoding é removido. A remoção do Accept-Encoding cabeçalho impede que o middleware compacte a resposta. Para obter mais informações, consulte NGINX: Compactação e descompressão. Esse problema é rastreado pela compactação de passagem Figure out para Nginx (dotnet/aspnetcore#5989).

Trabalhando com compactação dinâmica do IIS

Se você tiver um Módulo de Compactação Dinâmica do IIS ativo configurado no nível do servidor que deseja desabilitar para um aplicativo, desabilite o módulo com uma adição ao arquivo web.config . Para obter mais informações, consulte Desabilitando módulos do IIS.

Troubleshooting

Use uma ferramenta como o Fiddler ou o Firefox Browser Developer, que permitem definir o cabeçalho da Accept-Encoding solicitação e estudar os cabeçalhos de resposta, tamanho e corpo. Por defeito, o middleware de compressão de respostas comprime respostas que cumprem as seguintes condições:

• O Accept-Encoding cabeçalho está presente com um valor de br, gzip, ou codificação personalizada que corresponde a um provedor de compactação personalizado que estabeleceu. O valor não deve ser identity ou ter uma configuração de valor de qualidade (qvalue, q) de 0 (zero).
• O tipo MIME (Content-Type) deve ser definido e deve corresponder a um tipo MIME configurado no ResponseCompressionOptions.
• A solicitação não deve incluir o Content-Range cabeçalho.
• O pedido deve usar o protocolo insecure (http), a menos que o protocolo secure (https) esteja configurado nas opções de middleware de compressão de resposta. Observe o perigo descrito acima ao ativar a compactação segura de conteúdo.

Recursos adicionais

• Inicialização do aplicativo no ASP.NET Core
• ASP.NET Core middleware
• Mozilla Developer Network: Aceitação-Codificação
• RFC 9110 Seção 8.4.1: Codificação de conteúdo
• RFC 9110 Seção 8.4.1.3: Codificação Gzip
• Especificação do formato de arquivo GZIP versão 4.3