enable automatic gzip compression of responses

[yob]

This unconditionally enables envoys gzip http_filter, which will compress responses if the request indicates it can handle it (via a "accept-encoding: gzip" request header).

I've enabled it with no options, which means it gets the defaults, as
listed here. In envoy 1.7.0, they're:

    {
      "memory_level": 5,
      "content_length": 30",
      "compression_level": "DEFAULT",
      "compression_strategy": "DEFAULT",
      "content_type": [“application/javascript”, “application/json”, “application/xhtml+xml”, “image/svg+xml”, “text/css”, “text/html”, “text/plain”, “text/xml”],
      "disable_on_etag_header": false,
      "remove_accept_encoding_header": false,
      "window_bits": 12
    }

Note the list of content types that will be compressed. It's possible some users will want to customise this list, but for now I haven't exposed that option.

Fixes #310

Signed-off-by: James Healy james@yob.id.au

[yob]

To test this, I built a docker image with this branch and pushed it to a test cluster on GKE. Behind contour was a mini nginx server that returned a plain text debugging response.

Unfortunately, compressed responses make curl unhappy and I'm not sure why.

A request with curl that doesn't opt-in to compression:

$ curl -v http://echo.yob.id.au
* Rebuilt URL to: http://echo.yob.id.au/
*   Trying 35.197.162.175...         
* TCP_NODELAY set         
* Connected to echo.yob.id.au (35.197.162.175) port 80 (#0)
> GET / HTTP/1.1         
> Host: echo.yob.id.au            
> User-Agent: curl/7.61.0
> Accept: */*           
>                           
< HTTP/1.1 200 OK            
< server: envoy                   
< date: Thu, 04 Oct 2018 15:16:20 GMT
< content-type: text/plain
< content-length: 150                       
< expires: Thu, 04 Oct 2018 15:16:20 GMT                                                    
< cache-control: no-cache
< x-envoy-upstream-service-time: 0
<                                    
Server address: 10.60.0.28:80
Server name: echo-5b6df77c7c-p4vnt
Date: 04/Oct/2018:15:16:21 +0000        
URI: /                   
Request ID: 4b1b93a6a6cd1d89d51ccd667aee4f2a

A request from curl that opts-in to compression:

$ curl -sH 'Accept-encoding: gzip' -vv http://echo.yob.id.au
* Rebuilt URL to: http://echo.yob.id.au/
*   Trying 35.197.162.175...         
* TCP_NODELAY set         
* Connected to echo.yob.id.au (35.197.162.175) port 80 (#0)
> GET / HTTP/1.1         
> Host: echo.yob.id.au            
> User-Agent: curl/7.61.0
> Accept: */*           
> Accept-encoding: gzip     
>                               
< HTTP/1.1 200 OK       
< server: envoy
< date: Thu, 04 Oct 2018 15:15:43 GMT                                                                                                                                                                                < content-type: text/plain  
< expires: Thu, 04 Oct 2018 15:15:43 GMT
< cache-control: no-cache       
< x-envoy-upstream-service-time: 0
< vary: Accept-Encoding                     
< content-encoding: gzip                                                                                                                                                                                            
< transfer-encoding: chunked
<                                                         
* Failed writing body (0 != 155)
* Failed writing data                                                                                    
* stopped the pause stream!                     
* Closing connection 0

With wget, compression not opted in to:

$ wget -O /dev/stdout -S --quiet http://echo.yob.id.au                                                                                                                        
  HTTP/1.1 200 OK
  server: envoy
  date: Thu, 04 Oct 2018 15:17:49 GMT
  content-type: text/plain
  content-length: 150
  expires: Thu, 04 Oct 2018 15:17:48 GMT
  cache-control: no-cache
  x-envoy-upstream-service-time: 0
Server address: 10.60.0.28:80
Server name: echo-5b6df77c7c-p4vnt
Date: 04/Oct/2018:15:17:49 +0000
URI: /
Request ID: 919cb84beda14c1fc21b7fb850792afe

With wget, compression opted in to:

$ wget -O /dev/stdout -S --compression=gzip --quiet http://echo.yob.id.au                                                                                                     
  HTTP/1.1 200 OK
  server: envoy
  date: Thu, 04 Oct 2018 15:17:12 GMT
  content-type: text/plain
  expires: Thu, 04 Oct 2018 15:17:11 GMT
  cache-control: no-cache
  x-envoy-upstream-service-time: 0
  vary: Accept-Encoding
  content-encoding: gzip
  transfer-encoding: chunked
Server address: 10.60.0.28:80
Server name: echo-5b6df77c7c-p4vnt
Date: 04/Oct/2018:15:17:12 +0000
URI: /

[davecheney]

Thank you very much for this. I'm glad this was a simple change :)

[yob]

No worries, it was mostly out of self interest. We're migrating to contour, and had noticed a performance regression compared to our older infrastructure.

The error from curl is a worry though. I'd like to know why it's unhappy with gzipped responses.

[davecheney]

@yob this looks fine to me. the curl error is caused, i think, by manually forcing the Accept-encoding header. This causes the remote to send back compressed data which causes curl to freak out because it doesn't want to write binary data to a file.

% curl -H "accept-encoding: gzip" https://httpbin.davecheney.com/encoding/utf8 > /tmp/t && file /tmp/t
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  7128    0  7128    0     0  30724      0 --:--:-- --:--:-- --:--:-- 30724
/tmp/t: gzip compressed data, max speed, from Unix

works fine.

My version of curl also supports a --compressed flag which handles compression transparently.

[bourquep]

If I wanted to enable compression for another content type, how should I proceed?