asp.net core middleware to send compressed static files to the browser without having to compress on demand, also has support for sending more advanced image formats when the browser indicates that i has support for it.
In my project, I can see that alternative encodings for images are correctly served (for example, PNG is requested, WEBP is returned).
But this doesn't seem to be the case for static .js, .css, .svg files etc. compressed via Brotli and GZip, at least when compressed and named as in the example Gulpfile.
For example, I'm serving app.js, app.js.br, and app.js.gz. In browser dev tools, a request/response for app.js shows a blank Content-Encoding value, whereas I expect it to be "br" or "gz". Am I misunderstanding the process? Or perhaps there's an extra initialization step necessary to enable Brotli and GZip?
(Note: initially I didn't even deploy app.js, since GZip is universally supported, so I didn't think the plain app.js file would ever be necessary. But then I observed that requests for app.js resulted in a 404, whereas I expected CompressedStaticFiles to intervene and return either the gz or br encoding, both of which were available and supported by the client. Depending on the outcome of this issue, I might open a separate issue on the necessity of unencoded resources.)
In my project, I can see that alternative encodings for images are correctly served (for example, PNG is requested, WEBP is returned).
But this doesn't seem to be the case for static .js, .css, .svg files etc. compressed via Brotli and GZip, at least when compressed and named as in the example Gulpfile.
For example, I'm serving app.js, app.js.br, and app.js.gz. In browser dev tools, a request/response for app.js shows a blank Content-Encoding value, whereas I expect it to be "br" or "gz". Am I misunderstanding the process? Or perhaps there's an extra initialization step necessary to enable Brotli and GZip?
(Note: initially I didn't even deploy app.js, since GZip is universally supported, so I didn't think the plain app.js file would ever be necessary. But then I observed that requests for app.js resulted in a 404, whereas I expected CompressedStaticFiles to intervene and return either the gz or br encoding, both of which were available and supported by the client. Depending on the outcome of this issue, I might open a separate issue on the necessity of unencoded resources.)