flask won't response 304 Not Modified due to Etag modification

[ITcarrot]

When browser try to get the same file again, due to the etag modification described in issue #15 , browser will send the modified etag to flask server. Therefore, flask server will return 200 OK with file contents instead of 304 because the etag is different. There will be a significant waste of network traffic, especially when serving static js and css files.

Expected behaviour, this happens when flask-compress is not involed during request:

GET /static/img/emoji1.png HTTP/1.1
Accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: zh-CN,zh;q=0.9
Connection: keep-alive
Host: 127.0.0.1:5000
If-Modified-Since: Wed, 17 Sep 2025 10:10:52 GMT
If-None-Match: "1758103852.0-22711-916066088"
Referer: http://127.0.0.1:5000/play/3
Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36
sec-ch-ua: "Chromium";v="140", "Not=A?Brand";v="24", "Google Chrome";v="140"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
====================
HTTP/1.1 304 NOT MODIFIED
Server: Werkzeug/3.1.3 Python/3.12.11
Date: Sun, 28 Sep 2025 07:23:06 GMT
Content-Disposition: inline; filename=emoji1.png
Cache-Control: no-cache
ETag: "1758103852.0-22711-916066088"
Date: Sun, 28 Sep 2025 07:23:06 GMT
Vary: Accept-Encoding
Connection: close

Current behaviour, this happens when flask-compress is involed during request:

GET /static/js/play.js HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: zh-CN,zh;q=0.9
Connection: keep-alive
Host: 127.0.0.1:5000
If-Modified-Since: Sun, 28 Sep 2025 05:55:55 GMT
If-None-Match: "1759038955.6423435-29319-4233694673:zstd"
Referer: http://127.0.0.1:5000/play/3
Sec-Fetch-Dest: script
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36
sec-ch-ua: "Chromium";v="140", "Not=A?Brand";v="24", "Google Chrome";v="140"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
=====================
HTTP/1.1 200 OK
Server: Werkzeug/3.1.3 Python/3.12.11
Date: Sun, 28 Sep 2025 07:23:06 GMT
Content-Disposition: inline; filename=play.js
Content-Type: text/javascript; charset=utf-8
Content-Length: 7996
Last-Modified: Sun, 28 Sep 2025 05:55:55 GMT
Cache-Control: no-cache
ETag: "1759038955.6423435-29319-4233694673:zstd"
Date: Sun, 28 Sep 2025 07:23:06 GMT
Vary: Accept-Encoding
Content-Encoding: zstd
Connection: close

I suggest three different ways to solve this issue:

1. Do not modify the etag. The simplest way to fix this, it aligns with flask's logic on etag but will violate the RFC standard.
2. Add an option to switch on/off etag modification.
3. Checking whether the files is modified again in flask-compress. This is most recommanded but will require more effort to write some code.

[alexprengere]

@ITcarrot what is your opinion of PR #67 ?

[ITcarrot]

@alexprengere

Thanks @jlopex for the PR.

I think COMPRESS_MUTATE_WEAK_ETAGS option is unnessary. Default to the new behavior.

1. Appending the compression algorithm to ETags was originally an RFC-driven change; leaving weak ETags unchanged is also RFC-compliant.
2. Flask uses strong ETags for files served from static / send_from_directory, so this change affects almost no one.
3. Browsers handle header parsing and decompression; most users don’t understand ETags, so adding this option will be confusing.
4. Users who intentionally use weak ETags are HTTP-savvy and know RFC rules; providing this flexibility isn’t the responsibility of a compression library.

For COMPRESS_EVALUATE_CONDITIONAL_REQUEST: keep it as an option but prefer it enabled by default in the future.

• The behavior of a Flask server using flask-compress should match native Flask — this should outweigh preserving the extension’s historical behavior.

• I understand this is a wide-impact change and needs caution, but I still expect this option to default on. Most developers are expecting flask-compress to save bandwidth for their server, but now it's wasting more by default.

[jlopex]

@ITcarrot if understand your comment correctly, you would prefer that COMPRESS_MUTATE_WEAK_ETAGS setting disappears and we made the weak etags to not be mutated by flask-compress always, this will be RFC compliant and we're not "breaking anything" by doing so and users who use weak etags wisely will get benefit of that little change, so we're fine changing the current flask-compression behaviour.

Then regarding the COMPRESS_EVALUATE_CONDITIONAL_REQUEST I do also agree with your vision, but I was a bit worried of the change as it could have implications that I could not foresee by pushing the make_conditional evaluation to all requests who fit under that clause, maybe a good approach is to do this staggered into two steps:

Push an initial change with the safe "do not mutate weak etags" approach + allowing flask-compress to start testing the COMPRESS_EVALUATE_CONDITIONAL_REQUEST setting, then after a few months testing, and adjusting the behaviour make a new release to activate this evaluation as part of the flask-compress after_request handler?

[jlopex]

@ITcarrot and @alexprengere I added an extra commit to remove the COMPRESS_MUTATE_WEAK_ETAGS setting flag on my PR proposal, now weak ETags won't be mutated by flask-compress. Here is the change I did following the understanding I got from the review: 0b834bc

I would appreciate any feedback.

[alexprengere]

Very good work, thanks @jlopex ! I left a minor comment, then I plan to merge.
I agree to have COMPRESS_EVALUATE_CONDITIONAL_REQUEST default to True in the long run, but for now let's make a release where it is False, so we limit the number of breaking change in a single release 😉

[alexprengere]

As I merged PR #67, I will close this issue. If you want, you can open another one to make COMPRESS_EVALUATE_CONDITIONAL_REQUEST default to True in a next release.

[jlopex]

@alexprengere I saw your merge, are you planning doing a new release soon?

[alexprengere]

Most likely in the next couple of days, I would like to test it a bit more before.

[alexprengere]

1.19 is now on PyPI, I also pushed ed7907f to make the new behavior the default. I should publish 1.20 quite soon once I do more tests.