[master] 5e2b0d8 If gzip support is off, we still need to esi process

Dridi Boukelmoune dridi at varni.sh
Thu Mar 15 17:13:51 UTC 2018


On Thu, Mar 15, 2018 at 4:38 PM, Nils Goroll <nils.goroll at uplex.de> wrote:
>
> commit 5e2b0d8abda18e807b73ed2f6c0746688001e85b
> Author: Nils Goroll <nils.goroll at uplex.de>
> Date:   Thu Mar 15 16:30:38 2018 +0100
>
>     If gzip support is off, we still need to esi process
>
>     Ref: #2610 with another thank you to @fgsch
>
> diff --git a/bin/varnishd/cache/cache_fetch.c b/bin/varnishd/cache/cache_fetch.c
> index 9de528b..eb906b8 100644
> --- a/bin/varnishd/cache/cache_fetch.c
> +++ b/bin/varnishd/cache/cache_fetch.c
> @@ -531,10 +531,8 @@ vbf_figure_out_vfp(struct busyobj *bo)
>                 return (0);
>         }
>
> -       if (! cache_param->http_gzip_support) {
> +       if (! cache_param->http_gzip_support)
>                 bo->do_gzip = bo->do_gunzip = 0;
> -               return (0);
> -       }

My understanding was that http_gzip_support enabled means that Varnish
will sanitize the client Accept-Encoding header and ask backends to
compress (which they may not) and handle clients that support gzip or
not depending on what's present in storage.

Do we really want to neuter do_g[un]zip set _manually_ in VCL when
_automatic_ gzip support is disabled?

Dridi


More information about the varnish-commit mailing list