Meditação do Guru do Varnish 3.0 com erro FetchError TestGunzip no final

Question

Estou recebendo meditações intermitentes de guru em verniz (como em 50 pedidos e 3 voltam mal). No vernizlog, diz

   15 VCL_return   c hash
   15 HitPass      c 1394372109
   15 VCL_call     c pass pass
   15 Backend      c 17 default default
   15 TTL          c 1394372164 RFC 0 -1 -1 1384590297 0 1384590291 0 0
   15 VCL_call     c fetch
   15 TTL          c 1394372164 VCL 120 -1 -1 1384590297 -0
   15 VCL_return   c hit_for_pass
   15 ObjProtocol  c HTTP/1.1
   15 ObjResponse  c OK
   15 ObjHeader    c Date: Sat, 16 Nov 2013 08:24:51 GMT
   15 ObjHeader    c Server: Apache
   15 ObjHeader    c Accept-Ranges: bytes
   15 ObjHeader    c Cache-Control: max-age=0, no-cache
   15 ObjHeader    c Vary: Accept-Encoding
   15 ObjHeader    c X-Mod-Pagespeed: 1.5.27.2-2912
   15 ObjHeader    c Content-Encoding: gzip
   15 ObjHeader    c Content-Type: text/html; charset=utf-8
   15 Gzip         c u F - 3755 13624 80 0 0
   15 FetchError   c TestGunzip error at the very end
   15 VCL_call     c error deliver
   15 VCL_call     c deliver deliver
   15 TxProtocol   c HTTP/1.1
   15 TxStatus     c 503
   15 TxResponse   c Service Unavailable

Você pode ver o 15 FetchError c TestGunzip error at the very end , que é o problema. Não sei como interpretar a linha acima de Gzip c u F - 3755 13624 80 0 0 e não vejo por que isso é um problema. O site não relatou o problema de carregar páginas antes de colocar o verniz na frente.

Supondo que o verniz esteja apenas sendo mais restrito sobre o gzip do que os navegadores, tentei desativar o manuseio do gzip, por isso coloquei http_gzip_support em /etc/defaults/varnish :

DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,256m \
             -p http_gzip_support=off"

Isso não fez qualquer diferença. Eu agora estou sem ideias, qualquer ajuda seria muito apreciada.

    

Answer 1

Esta é a correção

if (beresp.status == 301 || beresp.status == 302) {
  if (beresp.http.Content-Encoding ~ "gzip") {
    if (beresp.http.Content-Length == "0") {
      unset beresp.http.Content-Encoding;
    }
  }
}

    

Answer 2

if (req.http.Accept-Encoding) {
    if (req.http.Accept-Encoding ~ "gzip") {
      # If the browser supports it, we'll use gzip.
      #set req.http.Accept-Encoding = "gzip";
      unset req.http.Accept-Encoding;
    }
    else if (req.http.Accept-Encoding ~ "deflate") {
      # Next, try deflate if it is supported.
      set req.http.Accept-Encoding = "deflate";
    }
    else {
      # Unknown algorithm. Remove it and send unencoded.
      unset req.http.Accept-Encoding;
    }
}

Eu coloquei o indefinido Accept-Encoding e quando a resposta volta do backend ele não tenta testar o TestGunZip. Isso é o que parece. Esta é a minha correção, porque eu também tive os mesmos problemas.

    

Answer 3

Às vezes, os vários backends precisam de mais tempo para carregar uma resposta para o verniz. Simplesmente, aumentar o seguinte geralmente ajuda:

backend default {
  .host = "x";
  .port = "x";
  .connect_timeout = 30s;
  .first_byte_timeout = 30s;
  .between_bytes_timeout = 30s;
  }