Support serving of pre-GZIP encoded files

[aspnet-hello]

From @DamianEdwards on Friday, July 25, 2014 11:42:51 AM

Pre-GZIPping files is seemingly becoming more popular. This involves running a tool ahead of deployment that creates GZIPped copies of suitable files in the site, e.g. site.js => site.js.gzip. Then the file serving aspect of the web server will serve the GZIPped file when appropriate.

Copied from original issue: aspnet/StaticFiles#7

[aspnet-hello]

From @tugberkugurlu on Friday, July 25, 2014 1:24:16 PM

👍 for this one.

[aspnet-hello]

From @nikmd23 on Wednesday, September 10, 2014 1:47:47 PM

I'd also like to point out that this shouldn't be about "pre-gziping", but rather pre-compressing in general, no matter what the encoding format is.

For example, Microsoft and Google have both played with improved encoding schemes (peerdist and sdch). At one point Chrome even included sdch in its Accept-Encoding header. Of course these two examples are a bit crumby since neither caught on, but new compression techniques come up all the time.

What this means is, in reality, I might want to pre-compile a file into multiple formats and have the proper one selected based on the Accept-Encoding. My content directory could have several "gzip compatible" files encoded with zopfli (*.gz), the same files encoded in sdch (*.sdch) as well as the original uncompressed files for really old browsers.

I think of this as being very analogous to keeping images in both *.jpg and *.webp formats, and serving the appropriate ones at the appropriate times.

[aspnet-hello]

From @resnyanskiy on Monday, January 18, 2016 6:37:35 PM

I found simple workaround based on URL redirect supported in HTTP:

class Startup
{
    private StaticFileOptions StaticFileOptions
    {
        get
        {
            return new StaticFileOptions
            {
                OnPrepareResponse = OnPrepareResponse
            };                
        }
    }

    private void OnPrepareResponse(StaticFileResponseContext context)
    {
        var file = context.File;
        var request = context.Context.Request;
        var response = context.Context.Response;

        if (file.Name.EndsWith(".gz"))
        {
            response.Headers[HeaderNames.ContentEncoding] = "gzip";
            return;
        }

        if (file.Name.IndexOf(".min.", StringComparison.OrdinalIgnoreCase) != -1)
        {
            var requestPath = request.Path.Value;
            var filePath = file.PhysicalPath;

            if (IsDevelopment)
            {
                if (File.Exists(filePath.Replace(".min.", ".")))
                {
                    response.StatusCode = (int)HttpStatusCode.TemporaryRedirect;
                    response.Headers[HeaderNames.Location] = requestPath.Replace(".min.", ".");
                }
            }
            else
            {
                var acceptEncoding = (string)request.Headers[HeaderNames.AcceptEncoding];
                if (acceptEncoding.IndexOf("gzip", StringComparison.OrdinalIgnoreCase) != -1)
                {
                    if (File.Exists(filePath + ".gz"))
                    {
                        response.StatusCode = (int)HttpStatusCode.MovedPermanently;
                        response.Headers[HeaderNames.Location] = requestPath + ".gz";
                    }
                }
            }
        }
    }

   public void Configure(IApplicationBuilder application)
   {
        application
            .UseDefaultFiles()
            .UseStaticFiles(StaticFileOptions)
    }
}

I used Wikipedia as reference. This approach also allows to use not minified files in development environment with no need to change links on client side.

I found that currect implementation of 'aspnet/StaticFiles' lacks of two feature:

1. Declarative setup of 'Content-Encoding' header. I suppose it can be implemented very easy - by adding second dictionary to FileExtensionContentTypeProvider.
2. Redirect support. Current design doesn't provide the ability to cancel invoke 'IHttpSendFileFeature.SendFileAsync/StreamCopyOperation.CopyToAsync'.

@davidfowl fyi.

[aspnet-hello]

From @nikmd23 on Monday, January 18, 2016 7:30:14 PM

In support of my comment above, both FireFox and Chrome will be shipping support for Brotli compression soon.

[aspnet-hello]

From @jods4 on Monday, February 22, 2016 8:44:29 AM

👍

Actually, even a good story for serving gzipped static files (with a cache, of course, since it's static compression) is currently lacking. I'm saying this in the "conventional", "IIS-kind" of way, as opposed to the build-time gzip generation.
Or did I miss something?

For those coming here from Google with dynamic content compression needs, you might try this gist:
https://gist.github.com/PinpointTownes/ac7059733afcf91ec319

[aspnet-hello]

From @JohannesRudolph on Tuesday, July 5, 2016 1:33:54 AM

Would it be beyond the scope of this to suggest that StaticFiles should optionally allow cached "on-demand" compression of files? (I.e. gzip on first request and put result to file system cache, serve gzip requests from there)

[aspnet-hello]

From @twilliamsgsnetx on Friday, July 22, 2016 4:39:03 AM

Really looking forward to being able to do this. I can go through all the trouble of bundling, minifying, tree shaking and gzipping to get things down to an absolute minimum size... but I can't serve those .js.gz files and it's problematic.

I'm also strugglin to get IIS to gzip itself as well, but that's for another area entirely.

[aspnet-hello]

From @neyromant on Friday, July 29, 2016 10:26:24 PM

#1584

https://github.com/AnderssonPeter/CompressedStaticFiles

[aspnet-hello]

From @dfaivre on Wednesday, February 15, 2017 4:34:00 AM

With Angular (2) creating *.gz files when doing --prod builds, it would be great to have this out of the box.

[aspnet-hello]

From @RehanSaeed on Wednesday, February 15, 2017 4:36:34 AM

Other related use cases are serving pre-brotli compressed (.br) files and also serving WebP (.webp) files instead of PNG/JPG/etc.

[aspnet-hello]

From @Tratcher on Friday, February 17, 2017 5:54:44 AM

@JohannesRudolph you should now be able to combine ResponseCaching, ResponseCompression, and StaticFiles to achieve dynamic compression and caching of static files. @JunTaoLuo this would be a good combo to test.