compress for certain content-type (not simply true/false)

[kachkaev]

Do you want to request a feature or report a bug?

feature

What did you do?

I'm trying to configure a mix of microservices behind traefik, some of which are static websites served by nginx and some are Node.js APIs. I would like traefik to be a bit more selective about what it compresses, since now the only options are either all or nothing.

Nginx has got a nice option called gzip_types, which makes it possible to compress text responses while skipping jpegs, archives, videos and other binaries. The format is the following:

server {
  # ...
  gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon image/bmp application/javascript application/json;
  # ...
}

Traefik could also use something similar in its compression middleware, i.e.:

## only certain content-types
compress = "text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon image/bmp application/javascript application/json"
## or all
compress = true
## or nothing
compress = false

Being selective about what content types to compress, traefik will save CPU resources both on the server and the client while removing a need to place nginx sidecar containers next to every API endpoint that does not do compression by design (e.g. Node.js GraphQL API).

The proposed change looks backwards-compatible. WDYT?

[kachkaev]

Just came across a Node.js module called compressible, which refers to content types using wildcards (at least in README). Perhaps the customized compress option in traefik could also be shortened in a similar way:

compress="text/* */*+json */*+text */*+xml"

Or maybe it can use proper regexps if that does not have any negative performance effects?

[kachkaev]

Just curious: what are the chances that this feature can become a part of 1.6? 😃 How big is the patch required?

[ldez]

@kachkaev not planned in 1.6 due to some design problem.

I will add this after 1.6

[kachkaev]

I'm wondering if this issue deserves to join 1.7 milestone. No worries if not, but in this case I'm curious how else to organise data compression in a micro-service environment 🤔

I see three alternative options at the moment, but all of them are pretty ugly:

1. Set compress = false in traefik.toml and make sure that each traefik-facing container compresses what it needs. This is straightforward for static nginx-based websites, but is problematic for Node.js apps. Gzipping inside a single-threaded Node.js process slows other work may require extra container instances to handle the incoming traffic. Besides, someone in the team needs to be made responsible for checking that all endpoinds have compression enabled to ensure that the clients never download unnecessary megabytes.

2. Set compress = false in traefik.toml and place sidecar containers with nginx reverse-proxies next to containers that do not support compression (for performance reasons or because their code cannot be changed). As with option 1, someone needs to remember to always add sidecar containers to microservices that do not support gzip.

3. Set compress = true in traefik.toml and watch everything including jpegs and videos flying to clients with compression enabled. This may require significantly more resources to be allocated to traefik pods and also implies CPU time wasting on the client (jpegs, videos, zip files, pdfs, etc. are compressed already, so gzipping them does not help). On the maintenance side, this may also cause problems like High disk read usage #3341 & Performance drop when using HTTPS together with compression in Kubernetes #1908 (comment).

All three options make it quite hard to achieve a single compression policy for the entire cluster. Traefik seems to be an ideal place to configure compression for certain content-types, so it'd be great if this issue was given a bit more attention.