最新消息:

Nginx反向代理使用的一些坑(续)–gzip,br压缩算法 与sub_filter的那些事

技术 admin 4477浏览 0评论

日常维护 jubt.net ,发现一个反向代理的网站失效了。

此网站在JavaScript脚本中会判断window.location.href是否为 官网地址,如果不是,则会通过在JavaScript脚本中设置 window.location.href 为官网地址,重定向到官网地址。(具体细节挺复杂,方案使用了挺有特色的编码方案,有机会再单写一篇文章讲解,此方案对反盗链、反镜像挺有借鉴意义。)。

在反向代理中使用了 Nginx反向代理使用的一些坑(续)–gzip/gunzip 与sub_filter的那些事  中描述的方案:

proxy_pass https://upstream.com/;
gunzip on;
sub_filter 'upstream.com' 'mydomain.com';
sub_filter_once off;

抓包查看页面跳转逻辑,发现sub_filter没起作用。

排查原因,发现反向代理服务器缺省没有设置 Accept-Encoding值, 网站返回的 Content-Encoding:br 。

因此怀疑可能是br压缩算法不支持导致的,因此在请求中增加Accept-Encoding “gzip,deflate”;

        proxy_set_header Sec-Fetch-Mode "navigate";
        proxy_set_header Sec-Fetch-Site "cross-site";
        proxy_set_header Cache-Control "max-age=0";
        proxy_set_header Accept-Encoding "gzip,deflate";

设置 Accept-Encoding “gzip,deflate”   后 sub_filter 生效了。

经过测试,发现此网站调整后会检测Accept-Encoding,如果客户端未设置Content-Encoding或设置为支持br压缩,则强制返回Content-Encoding:br。如果强制指定了只支持gzip,defalte,则Content-Encoding:gizp.defalter。

这里的br压缩算法指的是Brotli,维基百科的介绍

另外浏览器中常用的压缩算法还是:Accept-Encoding:gzip, deflate, sdch, br

常用HTTP 内容协商字段

请求头字段 说明 响应头字段
Accept 告知服务器发送何种媒体类型 Content-Type
Accept-Language 告知服务器发送何种语言 Content-Language
Accept-Charset 告知服务器发送何种字符集 Content-Type
Accept-Encoding 告知服务器采用何种压缩方式 Content-Encoding

例如客户端发送以下请求头:

Accept-Encoding:gzip,deflate,br

浏览器的响应头可能是这样的:

Content-Encoding: br

 

转载请注明:出家如初,成佛有余 » Nginx反向代理使用的一些坑(续)–gzip,br压缩算法 与sub_filter的那些事

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址