CompressedStaticFiles
CompressedStaticFiles copied to clipboard
Feature Request / Issue: pre-compressed gzip .gz files being served with response header content-encoding: br
Summary:
I am running a .net 9.0 web app. I have pre-compressed some bundle.js files using gzip to produce bundle.js.gz files.
When requesting bundle.js files, the compressed .gz files are successfully being returned, however, the content encoding is set to content-encoding: br in the response headers.
Expected Outcome:
I was expecting the response headers to include the content-encoding: gzip header for pre-compressed .gz files.
Hi thanks for notifying me of the issue, Could you see if you can submit a PR that either solves the issue or recreates it using a unit test or both?
Hi @AnderssonPeter, I created a branch to create a PR for this. As a start, I upgraded the solution projects to .net 9.0 (and updated all nuget packages, there was / is a vulnerability in one of the packages).
I wanted to push my branch to this repo to submit a PR, but i'm getting the following error when pushing my branch to github:
Permission to AnderssonPeter/CompressedStaticFiles.git denied to alexvenetis. fatal: unable to access 'https://github.com/AnderssonPeter/CompressedStaticFiles.git/': The requested URL returned error: 403
Hi you must create a fork, then commit on your fork and from there you can create a pull request 🙂
I was able to resolve my problem at the proxy server level. I am now having my proxy server serve the static compressed files before reaching the .net core application. So, no need for this nuget package anymore.
That said, for some strange reason, when I had this package installed, my .net core application logs were saying they were serving .br files that did not exist, and, the content-encoding response was br.
From .net core app logs:
Sending file. Request file: '/app.js'. Served file: '/app.js.br'. Original file size: 7246. Served file size: 1485
This is strange because app.js.br does not exist on my server, and there was no files of sizes 7246 or 1385.
I tried many things like pass all headers from the proxy server to the .net core app, but nothing seemed to work.
Also, I was not able to replicate this behaviour with a unit test.
I am still open to sending in a PR to upgrade this package to .net 9.0 and add a few unit tests I completed during my investigation, but, I was not able to resolve this issue.