【问题标题】:Varnish return(fetch/deliver) vs chunked encoding清漆返回(获取/交付)与分块编码
【发布时间】:2017-01-15 17:56:14
【问题描述】:

我正在尝试将清漆缓存响应分块...(这是可能的,对吗?)

我有以下场景:

1 - 缓存很干净,一切正常(服务清漆重启)

2 - 首次访问 www.mywebsite.com/page

(没有返回内容长度,并且有分块,太棒了!)

3 - 下次我访问页面时(比如简单的重新加载),它将被缓存.. 现在我得到了这个:

(现在我们有了内容长度......这意味着没有分块:(不是很好!)

在阅读了一些 Varnish 文档/博客(以及这个:http://book.varnish-software.com/4.0/chapters/VCL_Basics.html)之后,看起来有两个“最后”返回:return(fetch)return(deliver)强>。

当强制 return(fetch) 时,分块编码有效……但这也意味着请求不会被缓存,对吧?虽然 return(deliver) 缓存正确,但添加了 content-length 标头。

我已经尝试将这些添加到我的 default.vcl 文件中:

set beresp.do_esi = true; (at vcl_backend_response stage)

unset beresp.http.content-length; (at different stages, without success)

那么.. 如何让 Varnish 缓存与 Transfer-Encoding: 分块一起使用?

感谢您的关注!

【问题讨论】:

    标签: varnish varnish-vcl chunked-encoding transfer-encoding


    【解决方案1】:

    您是否有理由要分块发送它?当事先不知道内容长度时,分块传输编码是一种笨拙的解决方法。这里实际发生的是 Varnish 能够在第一次缓存后计算 gzip 压缩内容的长度,因此不必使用解决方法!请放心,在这种情况下您不会错过任何性能提升。

    【讨论】:

      猜你喜欢
      • 2011-12-31
      • 1970-01-01
      • 2023-02-10
      • 2011-05-25
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2023-04-01
      相关资源
      最近更新 更多