Gzip 压缩中间件在 asp.net core 2.0 中不起作用

Question

I am unable to get Gzip compression middleware to work in asp.net core 2.0 (or 2.1). I created a new project using the "Blank" Web Application template and have the following code in Startup.cs:

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

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseResponseCompression();

    app.Run(async (context) =>
        {
            context.Response.Headers.Add("Content-Type", "text/plain");
            await context.Response.WriteAsync("Hello World!");
        });
}

I verified that Chrome is sending "Accept-Encoding: gzip, deflate, br" in the request.

Accept-Encoding

However, the server is not gzip-encoding the response:

Content-Encoding

What am I doing wrong?

I found this discussion, and tried everything from there, but it didn't help.

Answer 1

I faced a similar problem (asp.net core on Mac)

Solution was to make sure response compression was called BEFORE static file serving.

    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }
        else
        {
            app.UseExceptionHandler("/Home/Error");
            app.UseHsts();
        }

        app.UseHttpsRedirection();
        app.UseCookiePolicy();

        // ordering matters here
        app.UseResponseCompression();
        app.UseStaticFiles();

        app.UseMvc(routes =>
        {
            routes.MapRoute(
                name: "default",
                template: "{controller=Home}/{action=Index}/{id?}");
        });
    }

After ordering it correctly I could see it in chrome under encoding br (Brotli Compression):

Answer 2

TL;DR: The code is fine, the issue with an environment.

First, please find out if you have any antivirus that intercepts incoming HTTP traffic. In my case, it was ESET Endpoint Antivirus. Second, Check your response for the presence of header Vary: Accept-Encoding . That indicates that Kestrel processed your request correctly and paid attention to Accept-Encoding request header.

If you do have antivirus what happens is that it sniffs incoming unencrypted traffic, sees gzip header and unpack message to check for malware or whatever. Then it passes the decompressed response to a browser and removes gzip content-encoding header.

You should turn off antivirus for some time, or test this feature on the environment without one.

Answer 3

From ASP.NET Core Middleware :

The following example demonstrates a middleware ordering where requests for static files are handled by the static file middleware before the response compression middleware. Static files are not compressed with this ordering of the middleware.

Below a screen capture of Fiddler showing the request and response with corresponding headers:

Answer 4

I was facing the same problem.

My observation is, Fiddler somehow doesn't show Content-Encoding, if it is done through ASP.net core middlewear. I am not sure why.

But If I look at the same request in Chrome debugger, I am able to see that information with the compressed data.

1. First row in image is without compression
2. Second row in image is with compression

Answer 5

If you use Fiddler, make sure the "Decode" function disabled or Fiddler will auto decode.