Varnish ESI:陌生字符

Question

我在使用Varnish ESI (Edge Side Includes)时遇到了一个问题:有时使用ESI的部分会显示奇怪的字符，如下图所示：

​

​

我该如何解决这个问题呢？有趣的是，这个问题有时会发生，但有时不会。

Answer 1

这看起来像是Varnish中gzip的一个奇怪的bug。如果你通过ESI得到this块，并且它不在缓存中(未命中)，你会得到这个奇怪的符号。如果你从缓存中得到这个块，一切都是正常的。解决方案是禁用内部路由的gzip：

if (req.url ~ "/_internal") {
    # Telling ESI that we do not support gzip
    remove req.http.Accept-Encoding;

.

Answer 2

看起来你有双倍压缩的ESI内容

Answer 3

This chapter解释了在ESI处理过程中Varnish如何与gzip一起工作。我真的喜欢这句话：

在理论上，希望在实践中，当你启用

时，你上面读到的所有内容也应该适用，如果不是，你应该报告它是一个错误。

长话短说，Varnish是如何工作的:在对页面的第一次请求(缓存未命中)期间，Varnish直接从web服务器呈现页面。在此之后- page被放入缓存存储，因此对于下一个请求，它将从存储中加载(缓存命中)。

不知何故，在第一次请求时，页面被渲染为未压缩的，但被放入存储gzipped的中。这就是bug发生的地方。因为nginx总是尝试用gzip压缩内容，所以我们在未压缩的页面中使用了gzip包含(在ESI期间)。

在提到的文档章节中解释了这种行为：

在查找过程中，我们忽略了对象变量中的任何“接受编码”：字符串，为了避免对象的gzip和gunzip版本，varnish可以按需进行gunzip。(我们在查找时实现了这个魔术，这样存储在持久性存储中的任何对象都可以在启用或不启用gzip支持的情况下使用。)

因此，这个问题可以通过某种尖峰来“解决”-通过强制Varnish在ESI处理期间总是发送未压缩的内容(正如klipach在one of the answers中提到的那样)：

# www.vcl

sub vcl_recv {
    # ...
    if (req.url ~ "/_internal") {
        # Telling ESI that we do not support gzip
        remove req.http.Accept-Encoding;

        return(lookup);
    }
    # ...
}