Disable gzip compression

Why it is disabled:
https://en.wikipedia.org/wiki/BREACH_%28security_exploit%29

Tested and applied the patch, works as advertised.

The patch as is works correct, but we need to find an alternative for the "aggregate and compress css" setting.
This setting should be split up or we should use something like https://www.drupal.org/project/advagg

First of all, the description in this issue is wrong. Javascript is no issue here. The two settings which are relevant are these:

1. Compress cached pages.
2. Aggregate and compress CSS files.

The first one is not a problem. The second one is compression AND aggregation. We only want to disable compression CSS files.

CSS and JSS compression are seperate variables, see also settings.php:

/**
 * CSS/JS aggregated file gzip compression:
 *
 * By default, when CSS or JS aggregation and clean URLs are enabled Drupal will
 * store a gzip compressed (.gz) copy of the aggregated files. If this file is
 * available then rewrite rules in the default .htaccess file will serve these
 * files to browsers that accept gzip encoded content. This allows pages to load
 * faster for these users and has minimal impact on server load. If you are
 * using a webserver other than Apache httpd, or a caching reverse proxy that is
 * configured to cache and compress these files itself you may want to uncomment
 * one or both of the below lines, which will prevent gzip files being stored.
 */
# $conf['css_gzip_compression'] = FALSE;
# $conf['js_gzip_compression'] = FALSE;

Why is the compression of aggregate JS and CSS an issue with Breach? Do those files contain secrets?

There is a need to disable compression of HTML. Note that PHP's zlib also compresses automatically. Maybe set http://php.net/manual/en/zlib.configuration.php#ini.zlib.output-compression in htaccess / via ini_set?

https://css-tricks.com/the-difference-between-minification-and-gzipping/

I believe aggregation shouldn't be affected and if the files can't be gezipped I request that the near best thing would be to minify the files css when they are aggregated.

Or is it a possibility to fix it as it states in wiki of mvwensen comment.
As a result, clients and servers are either forced to disable HTTP compression completely (thus reducing performance), or to adopt workarounds to try to foil BREACH in individual attack scenarios, such as using cross-site request forgery (CSRF) protection.[3]

Another suggested approach is to disable HTTP compression whenever the referrer header indicates a cross-site request, or when the header is not present.[4][5] This approach allows effective mitigation of the attack without losing functionality, only incurring a performance penalty on affected requests.

wrt #8,

"Why is the compression of aggregate JS and CSS an issue with Breach? Do those files contain secrets?"

Is this an issue after all? I hardly think so.

The primary issue is that there is no use in arguing with auditors. If their POV is 'disable gzip' then that is the hoop we need to jump through.

Of course BREACH needs mitigation on our side and there are several ways in which we could do that, but thanks to the auditors we need to disable gzip. Period.

I do very much agree that we should enable all other performance options, such as aggregating, minifying, etc.