Compactação de resposta em ASP.NET Core

A largura de banda de rede é um recurso limitado. A redução do tamanho da resposta geralmente aumenta a capacidade de resposta de um aplicativo, muitas vezes dramaticamente. Uma maneira de reduzir os tamanhos de carga é compactar as respostas de um aplicativo.

Compactação com HTTPS

As 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. Usar compactação com páginas geradas dinamicamente pode expor o aplicativo CRIME e BREACH ataques. CRIMEe BREACH ataques podem ser atenuados em ASP.NET Core com tokens antiforgery. Para obter mais informações, consulte Evitar ataques XSRF/CSRF (Solicitação Entre Sites) em ASP.NET Core. Para obter informações sobre como mitigar BREACH ataques, consulte mitigações em http://www.breachattack.com/

Mesmo quando EnableForHttps estiver desabilitado no aplicativo, o IIS, IIS Express e Serviço de Aplicativo do Azure podem aplicar gzip no servidor Web do IIS. Ao revisar cabeçalhos de resposta, anote o valor do servidor . Um valor de cabeçalho de resposta inesperado content-encoding pode ser o resultado do servidor Web e não da configuração do aplicativo ASP.NET Core.

Quando usar middleware de compactação de resposta

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

Use o Middleware de Compactação de Resposta quando o aplicativo for:

Compactação de resposta

Normalmente, qualquer resposta não compactada nativamente pode se beneficiar da compactaçã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 compactar ainda mais uma resposta compactada nativamente, qualquer pequena redução extra no tamanho e no tempo de transmissão provavelmente será ofuscada pelo tempo necessário para processar a compactaçã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 compactação de arquivos pequenos pode produzir um arquivo compactado maior que o arquivo não compactado.

Quando um cliente pode processar conteúdo compactado, o cliente deve informar o servidor sobre seus recursos 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 compatíveis com o middleware de compactação de resposta são mostradas na tabela a seguir.

Accept-Encoding valores de cabeçalho Middleware com suporte Descrição
br Sim (padrão) Formato de dados compactados brotli
deflate No Formato de dados compactados DEFLATE
exi No Intercâmbio XML eficiente do W3C
gzip Sim Formato de arquivo Gzip
identity Yes Identificador "Sem codificação": a resposta não deve ser codificada.
pack200-gzip No Formato de transferência de rede para arquivos Java
* Sim Qualquer codificação de conteúdo disponível não solicitada explicitamente

Para obter mais informações, consulte a lista de codificação de conteúdo oficial do IANA.

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

O middleware de compactação de resposta é capaz de reagir à ponderação de valor de qualidade (qvalue) qquando enviado pelo cliente para priorizar esquemas de compactação. Para obter mais informações, consulte RFC 7231: Accept-Encoding.

Os algoritmos de compactação estão sujeitos a uma compensação entre a velocidade de compactação e a eficácia da compactação. A eficácia nesse contexto refere-se ao tamanho da saída após a compactação. O menor tamanho é obtido pela compactação ideal.

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

Cabeçalho Função
Accept-Encoding Enviado do cliente para o servidor para indicar os esquemas de codificação de conteúdo aceitáveis para o cliente.
Content-Encoding Enviado do servidor para o cliente para indicar a codificação do conteúdo na carga.
Content-Length Quando a compactação ocorre, o Content-Length cabeçalho é removido, pois o conteúdo do corpo é alterado quando a resposta é compactada.
Content-MD5 Quando a compactação ocorre, o Content-MD5 cabeçalho é removido, já que o conteúdo do corpo foi alterado e o hash não é mais válido.
Content-Type Especifica o tipo MIME do conteúdo. Cada resposta deve especificar seu Content-Type. O middleware de compactação de resposta verifica esse valor para determinar se a resposta deve ser compactada. O middleware de compactação de resposta especifica um conjunto de tipos MIME padrão que ele pode codificar e eles podem ser substituídos ou adicionados.
Vary Quando enviado pelo servidor com um valor de Accept-Encoding clientes e proxies, o Vary cabeçalho indica ao cliente ou proxy que ele deve armazenar em cache (variar) respostas com base no valor do Accept-Encoding cabeçalho da solicitação. O resultado do retorno de conteúdo com o Vary: Accept-Encoding cabeçalho é que as respostas compactadas e não compactadas são armazenadas em cache separadamente.

Explore os recursos do Middleware de Compactação de Resposta com o aplicativo de exemplo. O exemplo ilustra:

  • A compactação de respostas de aplicativo usando Gzip e provedores de compactaçã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.

Configuração

O código a seguir mostra como habilitar o Middleware de Compactação de Resposta para tipos mime padrão e provedores de compactação (Brotli e Gzip):

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
});

var app = builder.Build();

app.UseResponseCompression();

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

app.Run();

Observações:

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:

  • Selecione a guia de rede.
  • Clique com o botão direito do mouse na solicitação na lista de solicitações de rede e selecione Editar e reenviar
  • Altere Accept-Encoding: de gzip, deflate, br para none.
  • Selecione Enviar.

Envie uma solicitação para o aplicativo de exemplo com um navegador usando as ferramentas de desenvolvedor e observe que a resposta é compactada. O Content-Encoding cabeçalho e Vary os cabeçalhos estão presentes na resposta.

Provedores

Provedores de compactação Brotli e Gzip

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

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

  • O provedor de compactação Brotli e o provedor de compactação Gzip são adicionados por padrão à matriz de provedores de compactação.
  • A compactação é padrão para a compactação Brotli quando o formato de dados compactados brotli é compatível com o cliente. Se o Brotli não for compatível com o cliente, a compactação será padronizada para gzip quando o cliente dá suporte à compactação Gzip.

Observação

Os links de documentação para a origem de referência do .NET geralmente carregam o branch padrão do repositório, que representa o desenvolvimento atual para a próxima versão do .NET. Para selecionar uma marca para uma versão específica, use a lista suspensa Alternar branches ou marcas . Para obter mais informações, consulte Como selecionar uma marca de versão de ASP.NET Core código-fonte (dotnet/AspNetCore.Docs #26205).

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 adicionado explicitamente, nenhum outro provedor de compactação será adicionado.

O seguinte código:

  • Habilita a compactação de resposta para solicitações HTTPS.
  • Adiciona os provedores de compactaçã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 compactação com BrotliCompressionProviderOptions e GzipCompressionProviderOptions. Os provedores de compactação Brotli e Gzip são padrão para 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 de compactação de resposta para compactação ideal.

Nível de Compactação Descrição
CompressionLevel.Fastest A compactação deve ser concluída o mais rápido possível, mesmo que a saída resultante não seja compactada de forma ideal.
CompressionLevel.NoCompression Nenhuma compactação deve ser executada.
CompressionLevel.Optimal As respostas devem ser compactadas de forma ideal, mesmo que a compactação leve mais tempo para ser concluída.
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();

Provedores personalizados

Criar implementações de compactação personalizadas com ICompressionProvider. Representa EncodingName a codificação de conteúdo que isso 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;
    }
}

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

tipos MIME

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

Observação

Os links de documentação para a origem de referência do .NET geralmente carregam o branch padrão do repositório, que representa o desenvolvimento atual para a próxima versão do .NET. Para selecionar uma marca para uma versão específica, use a lista suspensa Alternar branches ou marcas . Para obter mais informações, consulte Como selecionar uma marca de versão de ASP.NET Core código-fonte (dotnet/AspNetCore.Docs #26205).

Substitua ou acrescente tipos MIME por ResponseCompressionOptions.MimeTypes. Observe que tipos MIME curinga, como text/* não têm suporte. O aplicativo de exemplo adiciona um tipo MIME e image/svg+xml compacta e serve o ASP.NET Core banner.svg de imagem de faixa.

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();

Adicionando o cabeçalho Vary

Ao compactar respostas com base no cabeçalho daAccept-Encoding solicitação, pode haver várias versões compactadas e descompactadas da resposta. Para instruir os caches de cliente e proxy de que várias versões existem e devem ser armazenadas, o Vary cabeçalho é adicionado com um Accept-Encoding valor. O middleware de resposta adiciona o Vary cabeçalho automaticamente quando a resposta é compactada.

Observação

Os links de documentação para a origem de referência do .NET geralmente carregam o branch padrão do repositório, que representa o desenvolvimento atual para a próxima versão do .NET. Para selecionar uma marca para uma versão específica, use a lista suspensa Alternar branches ou marcas . Para obter mais informações, consulte Como selecionar uma marca de versão de ASP.NET Core código-fonte (dotnet/AspNetCore.Docs #26205).

Problema de middleware ao atrás de um proxy reverso do Nginx

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

Desabilitando a compactaçã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

Use uma ferramenta como o Desenvolvedor do Navegador Firefox ou o Postman, que permite definir o cabeçalho da Accept-Encoding solicitação e estudar os cabeçalhos, o tamanho e o corpo da resposta. Por padrão, o Middleware de Compactação de Resposta compacta as respostas que atendem às seguintes condições:

  • O Accept-Encoding cabeçalho está presente com um valor de br, *gzipou codificação personalizada que corresponde a um provedor de compactação personalizado. O valor não deve ser identity ou ter um valor de qualidade (qvalue, q) configuração de 0 (zero).
  • O tipo MIME (Content-Type) deve ser definido e deve corresponder a ResponseCompressionOptionsum tipo MIME configurado no .
  • A solicitação não deve incluir o Content-Range cabeçalho.
  • A solicitação deve usar o protocolo inseguro (http), a menos que o protocolo seguro (https) esteja configurado nas opções de Middleware de Compactação de Resposta. Observe o perigo descrito acima ao habilitar a compactação de conteúdo segura.

Exemplo implantado pelo Azure

O aplicativo de exemplo depolizado no Azure tem o seguinte Program.cs arquivo:

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();

Recursos adicionais

Observação

Os links de documentação para a origem de referência do .NET geralmente carregam o branch padrão do repositório, que representa o desenvolvimento atual para a próxima versão do .NET. Para selecionar uma marca para uma versão específica, use a lista suspensa Alternar branches ou marcas . Para obter mais informações, consulte Como selecionar uma marca de versão de ASP.NET Core código-fonte (dotnet/AspNetCore.Docs #26205).

A largura de banda de rede é um recurso limitado. A redução do tamanho da resposta geralmente aumenta a capacidade de resposta de um aplicativo, muitas vezes dramaticamente. Uma maneira de reduzir os tamanhos de carga é compactar as respostas de um aplicativo.

Exibir ou baixar código de exemplo (como baixar)

Quando usar middleware de compactação de resposta

Use tecnologias de compactação de resposta baseada 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 suporte a compactação interna no momento.

Use o middleware de compactação de resposta quando estiver:

Compactação de resposta

Normalmente, qualquer resposta não compactada nativamente pode se beneficiar da compactaçã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 compactaçã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 compactação de arquivos pequenos pode produzir um arquivo compactado maior que o arquivo não compactado.

Quando um cliente pode processar conteúdo compactado, o cliente deve informar o servidor sobre seus recursos 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 compatíveis com o middleware são mostradas na tabela a seguir.

Accept-Encoding valores de cabeçalho Middleware com suporte Descrição
br Sim (padrão) Formato de dados compactados brotli
deflate No Formato de dados compactados DEFLATE
exi Não Intercâmbio XML eficiente do W3C
gzip Sim Formato de arquivo Gzip
identity Yes Identificador "Sem codificação": a resposta não deve ser codificada.
pack200-gzip No Formato de transferência de rede para arquivos Java
* Yes Qualquer codificação de conteúdo disponível não solicitada explicitamente

Para obter mais informações, consulte a lista de codificação de conteúdo oficial do 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 é capaz de reagir à ponderação de valor de qualidade (qvalue) qquando enviado pelo cliente para priorizar esquemas de compactação. Para obter mais informações, consulte RFC 7231: Accept-Encoding.

Os algoritmos de compactação estão sujeitos a uma compensação entre a velocidade de compactação e a eficácia da compactação. A eficácia nesse contexto refere-se ao tamanho da saída após a compactação. O menor tamanho é obtido pela compactação mais ideal .

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

Cabeçalho Função
Accept-Encoding Enviado do cliente para o servidor para indicar os esquemas de codificação de conteúdo aceitáveis para o cliente.
Content-Encoding Enviado do servidor para o cliente para indicar a codificação do conteúdo na carga.
Content-Length Quando a compactação ocorre, o Content-Length cabeçalho é removido, pois o conteúdo do corpo é alterado quando a resposta é compactada.
Content-MD5 Quando a compactação ocorre, o Content-MD5 cabeçalho é removido, já que o conteúdo do corpo foi alterado e o hash não é mais válido.
Content-Type Especifica o tipo MIME do conteúdo. Cada resposta deve especificar seu Content-Type. O middleware verifica esse valor para determinar se a resposta deve ser compactada. O middleware especifica um conjunto de tipos MIME padrão que ele pode codificar, mas você pode substituir ou adicionar tipos MIME.
Vary Quando enviado pelo servidor com um valor de Accept-Encoding clientes e proxies, o Vary cabeçalho indica ao cliente ou proxy que ele deve armazenar em cache (variar) respostas com base no valor do Accept-Encoding cabeçalho da solicitação. O resultado do retorno de conteúdo com o Vary: Accept-Encoding cabeçalho é que as respostas compactadas e não compactadas são armazenadas em cache separadamente.

Explore os recursos do Middleware de Compactação de Resposta com o aplicativo de exemplo. O exemplo ilustra:

  • A compactação de respostas de aplicativo usando Gzip e provedores de compactação personalizados.
  • Como adicionar um tipo MIME à lista padrão de tipos MIME para compactação.

Configuração

O código a seguir mostra como habilitar o Middleware de Compactação de Resposta para tipos mime padrão e provedores de compactação (Brotli e Gzip):

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

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

Observações:

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

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 e Vary os cabeçalhos não estão presentes na resposta.

Fiddler window showing result of a request without the Accept-Encoding header. The response isn't compressed.

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

Fiddler window showing result of a request with the Accept-Encoding header and a value of br. The Vary and Content-Encoding headers are added to the response. The response is compressed.

Provedores

Provedor de Compactação Brotli

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

Se nenhum provedor de compactação for adicionado explicitamente 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 compactação é padrão para a compactação Brotli quando o formato de dados compactados brotli é compatível com o cliente. Se o Brotli não for compatível com o cliente, a compactação será padronizada para gzip quando o cliente dá suporte à compactação Gzip.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();
}

O Provedor de Compactação Brotli deve ser adicionado quando todos os provedores de compactação são adicionados explicitamente:

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 compactação com BrotliCompressionProviderOptions. O Provedor de Compactação Brotli 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.

Nível de Compactação Descrição
CompressionLevel.Fastest A compactação deve ser concluída o mais rápido possível, mesmo que a saída resultante não seja compactada de forma ideal.
CompressionLevel.NoCompression Nenhuma compactação deve ser executada.
CompressionLevel.Optimal As respostas devem ser compactadas de forma ideal, mesmo que a compactação leve mais tempo para ser concluída.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();

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

Provedor de compactação Gzip

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

Se nenhum provedor de compactação for adicionado explicitamente 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 compactação é padrão para a compactação Brotli quando o formato de dados compactados brotli é compatível com o cliente. Se o Brotli não for compatível com o cliente, a compactação será padronizada para gzip quando o cliente dá suporte à compactação Gzip.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();
}

O Provedor de Compactação Gzip deve ser adicionado quando quaisquer provedores de compactação são adicionados explicitamente:

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 compactação com GzipCompressionProviderOptions. O Provedor de Compactação Gzip 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.

Nível de Compactação Descrição
CompressionLevel.Fastest A compactação deve ser concluída o mais rápido possível, mesmo que a saída resultante não seja compactada de forma ideal.
CompressionLevel.NoCompression Nenhuma compactação deve ser executada.
CompressionLevel.Optimal As respostas devem ser compactadas de forma ideal, mesmo que a compactação leve mais tempo para ser concluída.
public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression();

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

Provedores personalizados

Criar implementações de compactação personalizadas com ICompressionProvider. Representa EncodingName 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. O Vary cabeçalho e Content-Encoding os cabeçalhos estão presentes na resposta. O corpo da resposta (não mostrado) não é compactado pelo exemplo. 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.

Fiddler window showing result of a request with the Accept-Encoding header and a value of mycustomcompression. The Vary and Content-Encoding headers are added to the response.

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 acrescente tipos MIME pelas opções de Middleware de Compactação de Resposta. Observe que tipos MIME curinga, como text/* não têm suporte. O aplicativo de exemplo adiciona um tipo MIME e image/svg+xml compacta e serve a imagem de faixa de 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" });
    });
}

Compactação com protocolo seguro

As respostas compactadas em conexões seguras podem ser controladas com a opção EnableForHttps , que é desabilitada por padrão. O uso da compactação com páginas geradas dinamicamente pode levar a problemas de segurança, como ataques CRIME e ataques BREACH .

Adicionando 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 proxy de que várias versões existem e devem ser armazenadas, o Vary cabeçalho é adicionado com um Accept-Encoding valor. No ASP.NET Core 2.0 ou posterior, o middleware adiciona o Vary cabeçalho automaticamente quando a resposta é compactada.

Problema de middleware ao atrás de um proxy reverso do Nginx

Quando uma solicitação é proxieda pelo Nginx, o Accept-Encoding cabeçalho é 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 Descompactação. Esse problema é acompanhado 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.

Solução de problemas

Use uma ferramenta como Fiddler, Firefox Browser Developer ou Postman, que permitem definir o Accept-Encoding cabeçalho da solicitação e estudar os cabeçalhos, o tamanho e o corpo da resposta. Por padrão, o Middleware de Compactação de Resposta compacta as respostas que atendem às seguintes condições:

  • O Accept-Encoding cabeçalho está presente com um valor de br, *gzipou codificação personalizada que corresponde a um provedor de compactação personalizado que você estabeleceu. O valor não deve ser identity ou ter um valor de qualidade (qvalue, q) configuração de 0 (zero).
  • O tipo MIME (Content-Type) deve ser definido e deve corresponder a ResponseCompressionOptionsum tipo MIME configurado no .
  • A solicitação não deve incluir o Content-Range cabeçalho.
  • A solicitação deve usar o protocolo inseguro (http), a menos que o protocolo seguro (https) esteja configurado nas opções de Middleware de Compactação de Resposta. Observe o perigo descrito acima ao habilitar a compactação de conteúdo segura.

Recursos adicionais