nginx - Varnish + nginx和压缩的SVG

Question

我需要一些帮助来了解这种情况下到底发生了什么。
我无法为自己的一生通过 Varnish 提供此svg文件。

我的设置是端口8080上的NGINX，作为端口80上Varnish的后端。非常简单。除此SVG文件外，其他所有方法都工作正常。请注意，我可以提供其他SVG文件了!但是，查看文件标记似乎与其他标记几乎相同。虽然通过nginx提供服务，但效果很好。

检查这一行-Gunzip错误:-3(错误的 header 检查)

上面的整个varnishlog。

*   << BeReq    >> 458807
-   Begin          bereq 458806 fetch
-   Timestamp      Start: 1476832525.282152 0.000000 0.000000
-   BereqMethod    GET
-   BereqURL       /images/logo-fibersals.svg
-   BereqProtocol  HTTP/1.1
-   BereqHeader    Host: fibersals.com.br
-   BereqHeader    Upgrade-Insecure-Requests: 1
-   BereqHeader    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
-   BereqHeader    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
-   BereqHeader    Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4,es;q=0.2
-   BereqHeader    X-Forwarded-For: 179.177.210.249, 179.177.210.249
-   BereqHeader    Accept-Encoding: gzip
-   BereqHeader    X-Varnish: 458807
-   VCL_call       BACKEND_FETCH
-   VCL_return     fetch
-   BackendOpen    29 boot.default 127.0.0.1 8080 127.0.0.1 43215
-   BackendStart   127.0.0.1 8080
-   Timestamp      Bereq: 1476832525.282200 0.000048 0.000048
-   Timestamp      Beresp: 1476832525.283278 0.001127 0.001079
-   BerespProtocol HTTP/1.1
-   BerespStatus   200
-   BerespReason   OK
-   BerespHeader   Content-Type: image/svg+xml
-   BerespHeader   Connection: keep-alive
-   BerespHeader   Server: nginx
-   BerespHeader   Last-Modified: Tue, 18 Oct 2016 21:34:00 GMT
-   BerespHeader   Vary: Accept-Encoding
-   BerespHeader   ETag: "58069548-24f6"
-   BerespHeader   X-XSS-Protection: 1; mode=block
-   BerespHeader   X-Frame-Options: SAMEORIGIN
-   BerespHeader   X-Content-Type-Options: nosniff
-   BerespHeader   Accept-Ranges: bytes
-   BerespHeader   Date: Tue, 18 Oct 2016 21:34:15 GMT
-   BerespHeader   Expires: Thu, 31 Dec 2037 23:55:55 GMT
-   BerespHeader   X-Original-Content-Length: 9462
-   BerespHeader   Content-Encoding: gzip
-   BerespHeader   Content-Length: 3684
-   BerespHeader   Vary: Accept-Encoding
-   BerespHeader   ETag: "58069548-24f6"
-   BerespHeader   Cache-Control: max-age=315360000
-   BerespHeader   X-XSS-Protection: 1; mode=block
-   BerespHeader   X-Frame-Options: SAMEORIGIN
-   BerespHeader   X-Content-Type-Options: nosniff
-   BerespHeader   Accept-Ranges: bytes
-   TTL            RFC 315360000 10 -1 1476832525 1476832525 1476826455 2145916555 315360000
-   VCL_call       BACKEND_RESPONSE
-   TTL            VCL 315360000 259200 0 1476832525
-   VCL_return     deliver
-   Storage        malloc s0
-   ObjProtocol    HTTP/1.1
-   ObjStatus      200
-   ObjReason      OK
-   ObjHeader      Content-Type: image/svg+xml
-   ObjHeader      Server: nginx
-   ObjHeader      Last-Modified: Tue, 18 Oct 2016 21:34:00 GMT
-   ObjHeader      Vary: Accept-Encoding, Accept-Encoding
-   ObjHeader      ETag: "58069548-24f6"
-   ObjHeader      X-XSS-Protection: 1; mode=block
-   ObjHeader      X-Frame-Options: SAMEORIGIN
-   ObjHeader      X-Content-Type-Options: nosniff
-   ObjHeader      Date: Tue, 18 Oct 2016 21:34:15 GMT
-   ObjHeader      Expires: Thu, 31 Dec 2037 23:55:55 GMT
-   ObjHeader      X-Original-Content-Length: 9462
-   ObjHeader      Content-Encoding: gzip
-   ObjHeader      Content-Length: 3684
-   ObjHeader      ETag: "58069548-24f6"
-   ObjHeader      Cache-Control: max-age=315360000
-   ObjHeader      X-XSS-Protection: 1; mode=block
-   ObjHeader      X-Frame-Options: SAMEORIGIN
-   ObjHeader      X-Content-Type-Options: nosniff
-   Fetch_Body     3 length stream
-   Gzip           Gunzip error: -3 (incorrect header check)
-   FetchError     Invalid Gzip data: incorrect header check
-   Gzip           u F - 2 0 0 0 0
-   BackendClose   29 boot.default
-   BereqAcct      472 0 472 649 0 649
-   End

现在我应该跳过SVG文件的gzip吗？我不明白的另一件事是，为什么 Varnish 弄乱了gzip压缩文件。它不应该只是将其缓存并传递吗？ Gzip还是没有gzip？似乎是出于某种原因试图对其进行解压缩。

谢谢!

Answer 1

您的 nginx 后端使用相同的值 Vary 两次返回 Accept-Encoding header 。我不知道这是否是一个问题，但我在你的日志中看到的唯一奇怪的事情......

我正在寻找分块传输问题(分块传输、内容长度和反向代理通常不会很好地混合在一起)，但这里似乎并非如此......