The documentation is a bit vague when it comes to mod_deflate, thus I would like to know what you think:
- don’t use it
- yea, no issues
- issues when doing x with mod_deflate
What exactly is the problem when using mod_deflate?
There is a clear statement that you should not use it:
https://docs.nextcloud.com/server/10/admin_manual/issues/general_troubleshooting.html#web-server-and-php-modules
It seems that it breaks up some things with the sync client (chunked upload, duplicates, …):
I think we have different opinions what clear means, but still, thank you for your reply.
You know there are different ways to configure mod_deflate. e.g. it makes no sense to compress already zipped files and you can limit the files it is used with. Let’s say only css and js files.
So why would that disrupt the operation of uploads and downloads?
As I mentioned, the documentation is vague and might be enough for a person who doesn’t know anything about IT.
I, on the other hand, would like to know what the reasons are and what you plan to do with these mod_deflate issues?
Are you working on a fix, or do you just say people can’t use a module that is used on millions of web sites to speed up traffic?
There is an issue with the E-Tag header:
In the latter there is a proposed patch for at least the web-traffic:
Thanks again, but you are proving my point somehow. These tickets are 3-4 years old.
Instead of fixing the problem, someone must have decided to ignore the fact that there’s an issue with the application and declared mod_deflate as a module non grata and just blamed mod_deflate. And that has been the status quo for the last 4 years.
Quite a few people put some effort in it at the time to make it run with ownCloud. That’s not exactly ignoring the problem but since then I haven’t found any recent activity. There has been some security concerns as well (Apache module deflate disables server cache · Issue #13219 · owncloud/core · GitHub).
Recently the client added a checksum feature to verify the correct transmission of a file, so this could perhaps help. Ideas on how to make it work are surely welcome.
A little late to the party, but this seems to have been resolved in NextCloud 12, where gzip was simply re-enabled. See https://github.com/nextcloud/documentation/pull/386
Maybe I’m wrong though.
But that is just a solution for nginx and not apache / mod_deflate, or am I wrong?
I had mod_deflate enabled already since long time, just fell over that issue/docs warning by change now. I never recognized some issue with it, that I could debug down to mod_deflate being enabled. Would be nice to have some update about that.
Okay, trying do disable the mod, I get a warning that it is an essential module and should not be disabled:
WARNING: The following essential module will be disabled. This might result in unexpected behavior and should NOT be done unless you know exactly what you are doing! deflate To continue type in the phrase 'Yes, do as I say!' or retry by passing '-f':
I guess thus at least on Raspbian Stretch current versions the module will be enabled by default. Is there a difference between enable and use the mod? 
After some server refresh, I fell over this question again. Is it still true, that mod_deflate causes issues? I think if yes, there should be something done about it. It is enabled by default, warning (as above), if one wants to disable. So I guess most users run around with Nextcloud + mod_deflate enabled, being affected by potential issues.
It’s now 2020. Is deflate / brotli safe to use? The manual hasn’t changed its recommendations for NC19 https://docs.nextcloud.com/server/19/admin_manual/issues/general_troubleshooting.html#web-server-and-php-modules
1 Like
I’ve used gzip and brottli output compression since a month now and not noticed any problems.
NC19
Apache 2.4.43
PHP 7.4.6 (php-fpm mode)
<Directory /var/www/domains/example.com/htdocs/nextcloud>
<If "%{HTTP:Accept-encoding} =~ /br/">
SetOutputFilter BROTLI_COMPRESS
</If>
<ElseIf "%{HTTP:Accept-encoding} =~ /deflate/">
SetOutputFilter DEFLATE
</ElseIf>
DirectoryIndex index.php
Options -Indexes +FollowSymlinks
AllowOverride All
Require all granted
<IfModule mod_dav.c>
Dav off
</IfModule>
SetEnv HOME "/var/www/domains/example.com/htdocs/nextcloud"
SetEnv HTTP_HOME "/var/www/domains/example.com/htdocs/nextcloud"
</Directory>
<FilesMatch "\.php$">
SetHandler "proxy:unix:/run/php-fpm/php-fpm.socket|fcgi://localhost"
</FilesMatch>
Hmm, aren’t they supposed to be limited to text files? e.g. in your current setup brotli and deflate also compress image files.
something like:
AddOutputFilterByType DEFLATE application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rdf+xml application/rss+xml application
/schema+json application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-javascript application/x-web-app-manifest+json application/xhtml+xml application/xml fo
nt/eot font/opentype image/bmp image/svg+xml image/vnd.microsoft.icon image/x-icon text/cache-manifest text/css text/html text/javascript text/plain text/vcard text/vnd.rim.location.xloc text/
vtt text/x-component text/x-cross-domain-policy text/xml
Yes in you’re right. Wasn’t sure that filterbytype worked with php fpm?
Update: Didn’t work to use AddOutputFilterByType. I tested with https://nixcp.com/tools/brotli-test/ and https://tools.keycdn.com/brotli-test
I am using it with deflate and php-fpm and it seems to work. At least the headers tell me so.
Strange, I will have to look into this. It’s in my very interest to get this working…
(Maybe the problem is with the combination of the If and the AddOutputFilterByType directives.)
Ok, on my server it works. I use the following in an include file and use the Include directive when I need compression:
<If "%{HTTP:Accept-encoding} =~ /br/">
AddOutputFilterByType BROTLI_COMPRESS application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rdf+xml application/rss+xml application/schema+json application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-javascript application/x-web-app-manifest+json application/xhtml+xml application/xml font/eot font/opentype image/bmp image/svg+xml image/vnd.microsoft.icon image/x-icon text/cache-manifest text/css text/html text/javascript text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy text/xml
</If>
<ElseIf "%{HTTP:Accept-encoding} =~ /(deflate|gzip)/">
AddOutputFilterByType DEFLATE application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rdf+xml application/rss+xml application/schema+json application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-javascript application/x-web-app-manifest+json application/xhtml+xml application/xml font/eot font/opentype image/bmp image/svg+xml image/vnd.microsoft.icon image/x-icon text/cache-manifest text/css text/html text/javascript text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy text/xml
</ElseIf>
Another way to easily implement brotli/gzip:
NC19
Apache 2.4.43
PHP 7.4.8 (php-fpm mode)
Add the following to NC’s .htaccess-file:
https://www.giftofspeed.com/gzip-test/ will show:
Brotli Is Enabled
https://nixcp.com/tools/brotli-test/ will show:
Cool! https://cloud.mydomain.com supports Brotli compression.
Note that you might have to re-add the lines into .htaccess after every upgrade of NC.
Unfortunately this setup has a slight issue. I can’t copy and paste, because you took a screenshot of text. (I’m sorry, but I never understand how people can take a screeenshot of text. Something wrong with their brain maybe. Next step is to add the image of text to a Word document, zip the document and attach it.)
The SetEnvIfNoCase directive only excludes certain extensions from using brotli. What about, if there’s image data in an extension .xyz or what about zip/tar.gz/7z archives?
Or other binary files, which don’t react well to compression?
Yes, it is a valid setup, but you will run into some issues sooner than later.
Those issues is the point of this thread. There used to be problems with, I think broken uploads, way back. It seems NC19 or PHP 7.3+ is better now.
Thanks. I’ll look at that. It would save some cpu cycles. So that’s always good.