Varnish 3 exécute gunzip même si le pipeline entier est gzippé.

Je suis en train de remanier ma VCL Varnish et je n'arrive pas à résoudre ce problème.

Varnish 3.0 supporte nativement le contenu gzippé, et il semble essentiellement faire la bonne chose. Voir aussi : https://stackoverflow.com/a/12962493/35434

Cependant, Varnish effectue toujours une étape gunzip, selon varnishlog, même si le client demande un contenu gzippé et que le backend répond avec un contenu gzippé. Selon la documentation de Varnish, Varnish utilise par défaut do_gzip=true, et stocke également les objets de cache compressés. Alors, pourquoi le gunzip ?

Voici les entrées de journal pertinentes :

11 RxURL        c /javascripts/general.js
11 RxHeader     c Accept-Encoding: deflate, gzip
11 VCL_call     c fetch
13 TxHeader     b Accept-Encoding: gzip
13 RxHeader     b Content-Encoding: gzip
13 RxHeader     b Content-Type: application/javascript
11 Gzip         c u F - 1554 4476 80 80 12365
11 VCL_call     c deliver
11 TxHeader     c Content-Encoding: gzip

Comme vous pouvez le voir, l'ensemble du pipeline supporte gzip, mais Varnish effectue un gunzip pendant vcl_fetch. Je suppose qu'il stocke les objets compressés, et comme vous pouvez le voir, il les livre également compressés.

Après cette requête, varnishstat montre que l'opération gunzip a eu lieu :

$ varnishstat -1 | grep zip
n_gzip                       0         0.00 Gzip operations
n_gunzip                     1         0.00 Gunzip operations

Note : Ma VCL a pas de gzip du tout, et je ne fais rien avec le corps de l'objet. Je me fie aux valeurs par défaut, c'est pourquoi je ne montre pas la VCL.

Une opération gunzip est relativement légère, mais j'aimerais quand même comprendre pourquoi, et éventuellement éviter quelques centaines de milliers d'opérations.