CompressedStaticFiles icon indicating copy to clipboard operation
CompressedStaticFiles copied to clipboard

Feature Request / Issue: pre-compressed gzip .gz files being served with response header content-encoding: br

Open alexvenetis opened this issue 11 months ago • 4 comments

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.

alexvenetis avatar Jan 06 '25 05:01 alexvenetis

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?

AnderssonPeter avatar Jan 06 '25 10:01 AnderssonPeter

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

alexvenetis avatar Jan 07 '25 03:01 alexvenetis

Hi you must create a fork, then commit on your fork and from there you can create a pull request 🙂

AnderssonPeter avatar Jan 07 '25 07:01 AnderssonPeter

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.

alexvenetis avatar Jan 08 '25 02:01 alexvenetis