Nginx反向代理理解误区之proxy_cookie_domain

栏目: 服务器 · Nginx · 发布时间: 5年前

内容简介:Nginx做反向代理的时候,我们一般习惯添加proxy_cookie_domain配置,来做cookie的域名转换,比如在之前的博客中我也是这么写的,但是最近在项目中发现,不配置这个属性,依然运转正常,背后冷风阵阵,我发现自己一直以来可能又理解错了这个选项,然后还在这给别人讲。。。我们首先来看下proxy_cookie_domain的官方定义,

基本内容

Nginx做反向代理的时候,我们一般习惯添加proxy_cookie_domain配置,来做cookie的域名转换,比如

...
location /api {
   proxy_pass https://b.test.com;
   proxy_cookie_domain b.test.com  a.test.com;
}       
...

在之前的博客中我也是这么写的,但是最近在项目中发现,不配置这个属性,依然运转正常,背后冷风阵阵,我发现自己一直以来可能又理解错了这个选项,然后还在这给别人讲。。。

我们首先来看下proxy_cookie_domain的官方定义,

Syntax: proxy_cookie_domain off;

proxy_cookie_domain domain replacement;

Default:

proxy_cookie_domain off;

Context: http, server, location

This directive appeared in version 1.1.15.

Sets a text that should be changed in the domain attribute of the “Set-Cookie” header fields of a proxied server response. Suppose a proxied server returned the “Set-Cookie” header field with the attribute “domain=localhost”. The directive proxy_cookie_domain localhost example.org will rewrite this attribute to “domain=example.org”.

翻译过来就是 proxy_cookie_domain参数的作用是转换response的set-cookie header中的domain选项,由后端设置的域名domain转换成你的域名replacement,来保证cookie的顺利传递并写入到当前页面中,注意proxy_cookie_domain负责的只是处理response set-cookie头中的domain属性,仅此而已。

但是我们知道response在写set-cookie的时候,domain是一个可选项,并不是必填项,所以经常能看到如下这种情况

Nginx反向代理理解误区之proxy_cookie_domain

这个时候由于set-cookie本身就没有domain内容,proxy_cookie_domain也就不没有必要了,这也是为什么在部分项目中不配置proxy_cookie_domain依然正常的原因。但是对于一些设置了domain的项目,比如

Nginx反向代理理解误区之proxy_cookie_domain

这种情况下当你用nginx做反向代理的时候,就必须要转换一下了。

误区回溯

说到这里,我们再看看之前的错误理解:

“proxy_cookie_domain的作用是实现前后端cookie域名转换,保证顺利传递”

乍一看好像也没错,但是现在想想,理解还是不够啊,因为proxy_cookie_domain的作用是单向的,并不是双向转换的。我们先看下cookie的传递过程,盗一张图先(懒得画了。。。)

Nginx反向代理理解误区之proxy_cookie_domain

浏览器在发送请求的时候,会在request header中带上cookie项(有内容的话),此时的cookie是一个字符串,一个key=value并用分号分割的字符串,

Nginx反向代理理解误区之proxy_cookie_domain

其中 并不包含任何域名信息 。这是因为浏览器在设置cookie选项的时候,所选取的内容都是缓存中接口域名下的。然后request的只要请求发送出去之后,cookie中有关domain信息其实是不存在的,它只是一个普通的字符串,随便proxy_pass到任何位置,都会正常携带下去。因此 在前端到后端的request的过程中,proxy_cookie_domain是没用的

而server端在做响应的时候,通过set-cookie的domain属性,可以控制cookie的生效域名目标,做到诸如二级域名cookie分离等等,如果前端接收到的set-cookie的domain和当前域名不一致,或者一级域名不一致(二级域名可以共享一级域名下的cookie),这个cookie在后续的通信中就是无效的,所以这里才需要去做domain的转换,也就是说 response中set-cookie的domain转换才是有意义的 ,这也正是proxy_cookie_domain的作用所在。

当reseponse的set-cookie中domain不去设置时,cookie顺利传入浏览器中,浏览器会自动设置这个cookie的生效域名为当前域名。

和这个类似的还有proxy_cookie_path属性,同样的该属性仅作用在修改response set-cookie的path属性,而一般情况下,用的也比较少。

唠叨两句

很多问题,有时候都是太过理所当然的以为它是怎么样的,并且生效了、达到目的了,我们就认为它是这样的了,但往往大脸就会在后面不期而至。多学习,多去关注一些底层的原理,才会发现自己理解的错误,望诸君共勉~

如果错误,欢迎指出~


以上所述就是小编给大家介绍的《Nginx反向代理理解误区之proxy_cookie_domain》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

琢石成器

琢石成器

罗云彬 / 电子工业出版社 / 2009-6 / 89.00元

Windows环境下32位汇编语言是一种全新的编程语言。它使用与C++语言相同的API接口,不仅可以开发出大型的软件,而且是了解操作系统运行细节的最佳方式。 本书从编写应用程序的角度,从“Hello,World!”这个简单的例子开始到编写多线程、注册表和网络通信等复杂的程序,通过70多个实例逐步深入Win32汇编语言编程的方方面面。 本书作者罗云彬拥有十余年汇编语言编程经验,是汇编编程......一起来看看 《琢石成器》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

html转js在线工具
html转js在线工具

html转js在线工具