Enable gzip by default

Seems current GitLab default configuration does not use gzip with nginx.

Here's what I got: By enabling gzip, it's able to reduce the transfer by around 1MB. GitLab.com is slow on both response and transfer, so I think it will help to reduce the lag.

gzip is disabled intentionally to avoid the CRIME security issue. See https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/security/crime_vulnerability.md for more information.

Status changed to closed

@razer6 I don't think that's right, Wikipedia says "As of September 2012, the CRIME exploit against SPDY and TLS-level compression was described as mitigated in the then-latest versions of the Chrome and Firefox web browsers, and Microsoft has confirmed that their Internet Explorer browser was not vulnerable to the exploit, as their browser doesn't support SPDY or TLS compression. Some websites have applied countermeasures at their end. The nginx web-server was not vulnerable to CRIME since 1.0.9/1.1.6 (October/November 2011) using OpenSSL 1.0.0+, and since 1.2.2/1.3.2 (June / July 2012) using all versions of OpenSSL". Their source for Chrome/Firefox is Ars Technica.

So unless people are running horribly outdated versions of nginx/OpenSSL on the server or Chrome/Firefox on the client, there's no problem. I don't think it's our responsibility to protect people using outdated, insecure libraries on their servers, especially not almost four years later.

Maybe I'm misunderstanding why this is being considered an attack vector?

Per Google PageSpeed, we could reduce this page's size 1.4MB by enabling gzip. That's a huge difference. I'd need to know what the exact reason (e.g. what library/browser) is for disabling gzip, but we should really enable it ASAP.

mentioned in issue gitlab-com/operations#42 (closed)

If we could that, that would be awesome. @jvanbaarsen Could you chime on on that topic?

The "successor" of CRIME is BREACH, which isn't fixed. He may be talking about that.

Status changed to reopened

Sorry pressed the wrong button when page jumped.

@razer6 I don't have much knowledge about CRIME, so probably not the best person to chime in :-) Maybe @jacobvosmaer know more about this?

@jvanbaarsen Oh wrong mention. I wanted to mention @jacobvosmaer originally.

Apologies if I came off as rude or anything, really wanted to make sure this was looked at.

@connorshea this looks like the biggest win is compressing assets, which is unrelated to crime and should already happen.

It looks like this is affecting us https://mattbrictson.com/gzipped-assets-nginx-rails-42

Recent Rails version stopped creating .gz version of the assets. This makes gitlab-workhorse fall back to serving the uncompressed asset files.

It looks like asset gzipping was dropped because of etag issues. I think what we should do is:

• change the asset compilation process ( :( ) to include generating .gz files
• in gitlab-workhorse, forcibly remove the etag header when serving a .gz file just to be sure.

I put a frowny on 'change the asset precompilation process' because it may mean adding another rake task to the update/installation process, which is a pain for installations from source.

After discussion with @jnijhof I realized we could also let gitlab-workhorse compress files in /assets/ on the fly, storing the result in memory. That would be much easier to deploy.

The easiest (least effort) scenario would be if rake assets:precompile started creating .gz files again because then the would automatically be picked up by workhorse and we would get a good mark from google pagespeed again. But I am not sure if we can count on that happening.

More recent versions of Sprockets added GZIP again, I should note. We can probably just upgrade Sprockets to fix it.

@jacobvosmaer upgrading to Sprockets 3.5.2 will fix this issue. See the 3.x Changelog. 3.5.0 "reintroduced Gzip file generation for non-binary assets" and the patch releases fixed some bugs.

That should make rake assets:precompile produce gzip'd files again. Can we get this issue scheduled for 8.7 @DouweM @rspeicher?

@connorshea awesome, thanks for looking into that.

Milestone changed to 8.7

Added ~18308 label

@connorshea Scheduled. Feel free to work on it :)

I'm testing Sprockets 3.5.2 locally and have modified the development.rb to include config.action_controller.perform_caching = true and config.assets.compress = true, and run rake assets:precompile, but it's still not serving GZIP'd assets. The Request Headers includes Accept-Encoding: gzip, deflate, sdch, I'm using the GDK, master for CE, and using ./run. Do I need to modify my nginx config or anything?

I love Sprockets sometimes, but it's also the worst part of Rails other times. :(

Anyone want to try to tinker with it? I can push to my fork.

mentioned in merge request !3424 (merged)

Figured it out! We need to update both sprockets-rails and sprockets in order for GZIP to work. Can I upgrade sprockets-rails to 3.0.4 in the same MR as I update sprockets?

Enabling gzip, between just the application.css and application.js, will decrease the page load by about 1.4MB.

mentioned in merge request !3544 (merged)

Status changed to closed by commit 1647e3e8

@connorshea We didn't need to do anything for this beyond upgrading the gem?

@rspeicher good you asked, I was under the impression that config.assets.compress was set to true by default in the production environment, but apparently I was wrong and it has to be set explicitly. I'll open a new MR to fully enable it.

@connorshea Cool, I'll reopen this if you want to mark that new MR as closing it again.

Status changed to reopened

mentioned in merge request !3632 (merged)

mentioned in commit 1647e3e8

mentioned in commit 600b94cd

Status changed to closed by commit 44d9f52f

mentioned in commit 44d9f52f

mentioned in commit a2303417