Use brotli for all compressed HTTP responses

[r4co0n]

Describe the bug

Currently, not all compressed files being served by Apache use the same compression algorithm. Apparently, we wanted to enable brotli-compression only for some file types, similar to what is done with gzip compression for NGINX in Nextcloud's example configuration.

However, previously files seem to have been compressed using gzip, which now remains the compression algorithm for some responses not explicitly listed in the apache config.

Additionally, please note that our implementation of gzip compression seems to strip the Etag-header, not following the workaround in Nextcloud's example configuration. (GET https://nextcloud.example.org/ocs/v2.php/apps/notifications/api/v2/notifications, served uncompressed, contains the Response Header ETag, .../heartbeat as documented below, compressed with gzip, does not.

To Reproduce

Steps to reproduce the behavior:

1. Open the web devolopment tools of your favorite browser and open the request logging tool. (For Firefox: [Ctrl]+[Alt]+[K], select tab "Network")
2. Go to some webpage served by your nextcloud instance (I used the dashboard.)
3. Inspect the requests made, and find that some do use compression, but gzip, indicated by the Response Header Content-Encoding: gzip. These include:
   • GET https://nextcloud.example.org/index.php
   • PUT https://nextcloud.example.org/index.php/apps/user_status/heartbeat
   • GET https://nextcloud.example.org/index.php/csrftoken
   • GET https://nextcloud.example.org/index.php/css/core/dd9a-cf97-server.css?v=d41d8cd98f00b204e9800998ecf8427e-a5cbde35 (Content-Type: text/css;charset=UTF-8)

Thanks to @pachulo for additional documentation regarding his PR #1447 following my question in release PR #1880.

I will try to find out why our Apache thinks to deliver stuff gzip-compressed and report back. P.S.: I already found some code in nextcloud/server compressing the responses using gzip itself, so Apache is just passing on already compressed responses, it seems.

In my opinion, some paths could (continue to) be excluded from compression, such as .../heartbeat, .../notifications and probably some other URLs we would need to identify. If this is helpful or a needlessly complex optimization remains up for debate.

Expected behavior

All compressed files delivered by Apache use brotli-compression as introduced with #1447.

Snap version

$ snap list nextcloud
Name       Version      Rev    Tracking       Publisher   Notes
nextcloud  22.2.0snap1  28575  latest/stable  nextcloud✓  -

[r4co0n]

Looking through nextcloud/server's code and mentions of gzip further, it seems that this is married to the application without a configuration option. We could only remove gzip from every request's header Accept-Encoding declarations, if I'm not mistaken, which somehow seems excessive.

Maybe this will become an issue that is closed without further action. Though this seems to be like something to raise upstream, at least, I don't really understand why there are differences in the compression type used for text/css, depending on if ;charset=UTF-8 is appended.

[kyrofa]

If this is helpful or a needlessly complex optimization remains up for debate.

Any discussion is helpful! Sadly it's out of my realm of expertise, so I will defer to @pachulo.

[github-actions[bot]]

This issue is stale because it has been without activity for 60 days. It will be closed after 7 more days of inactivity.

[pachulo]

Sorry, I forgot to check this. I will try to do these holidays.

[github-actions[bot]]

This issue is stale because it has been without activity for 60 days. It will be closed after 7 more days of inactivity.

[kyrofa]

@pachulo issues won't be touched by the stale bot if they're triaged to use one of these labels.

[StarSmasher44]

Seems like this is rather old.... But has there been any improvements upon moving/utilizing brotli over Gzip?