-
-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use brotli for all compressed HTTP responses #1882
Comments
Looking through 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 |
Any discussion is helpful! Sadly it's out of my realm of expertise, so I will defer to @pachulo. |
This issue is stale because it has been without activity for 60 days. It will be closed after 7 more days of inactivity. |
Sorry, I forgot to check this. I will try to do these holidays. |
This issue is stale because it has been without activity for 60 days. It will be closed after 7 more days of inactivity. |
@pachulo issues won't be touched by the stale bot if they're triaged to use one of these labels. |
Seems like this is rather old.... But has there been any improvements upon moving/utilizing brotli over Gzip? |
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 HeaderETag
,.../heartbeat
as documented below, compressed withgzip
, does not.To Reproduce
Steps to reproduce the behavior:
gzip
, indicated by the Response HeaderContent-Encoding: gzip
. These include: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 usinggzip
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
The text was updated successfully, but these errors were encountered: