1) $http_cookie -->获取Cookie请求头"所有值"
2) $COOKIE_flag -->获取Cookie请求头的"某个key"
[1]、'脱敏'场景在'日志'中只记录'非敏感'的key
[2]、由于nginx会进行'lowcase',将所有的字符转化为'小写',推荐使用$COOKIE_lowercase形式
3) nginx也可通过'map'获取指定的cookie
4) 理解了'Cookie'请求头的构成,就理解了'方法二'的正则
常见: 响应头中的'Cookie'头大,导致'400'报错
If the directive is specified on the server level,
the value from the 'default server' can be used --> "如何理解"?
解读: 如果指令是在'server'级别指定,则仅server为'默认server'才使用'该指令'
off: 不忽略无效的'请求头',让其'透传'过去
重点: nginx对ignore_invalid_headers'无效头'的判定
1) 就是'英文字母'、'数字'、'连字号'和'下划线'
2) 对'下划线'进行特殊处理,下划线可以通过'underscores_in_headers'控制
特殊场景: 需要'_下划线'、'.点 --> key为 a.b'
1) 如果'带invalid_header'且'打开ignore_invalid_headers on'配置,就会'输出日志'并忽略
2) error_log logs/error.log info;
3) error.log的'日志级别'有debug, info, notice, warn, error, crit, alert, emerg
4) 打开'error_log'的info日志,可以看到'告警'信息
client sent invalid header line: "xxxx" while reading client request headers
+++++++++ "(1) 属性的处理" +++++++++
常见:'domain'、'path'、'secure'、'httponly'、'samesite'属性'修改'
涉及'3'个指令:
[1]、proxy_cookie_domain --> 默认是'off'
特点:通过Set-Cookies中的'domain属性'来判断,进行'pdomain'属性的修改
[2]、proxy_cookie_path --> 默认是'off'
特点:通过Set-Cookies中的'path属性'来判断,进行'path'属性的修改
思考:正则形式是'第一个'还是'所有的'匹配
特殊1:proxy_cookie_path / "/;secure" --> "可以附加其它属性",使用'不规范'
特殊2:proxy_cookie_path '非'正则时候应该是'前缀替换',而不是'中间替换'或'全局替换'
[3]、proxy_cookie_flags --> 默认是'off','1.19.3'版本引入
特点:通过Set-Cookies中的'key'来判断,进行'相关属性'的修改
注意:每个指令的'default值',以及'指令'哪个'版本'提供的
补充:只是'单向'对'上游响应头Set-Cookies'的处理
说明:两个'维度' --> 基于'cookie-av'进行'av'修改;基于'key'进行'av'修改
'多指令'附加'细节':
1) 由于可能包含多个'Set-Cookies'响应头,nginx也可能包含多个'属性指令',以及多个'相同'指令
2) 某一个'Set-Cookies'经过相同指令'cookie-av'属性的洗礼,第一个'属性指令'匹配即'停止'
3) 再继续经过其它'cookie-av'处理
注意: 一些高级属性与'nginx版本'的适配
+++++++++ "(2) Set-Cookies响应头的处理" +++++++++
1) proxy_cache_valid '指令'
如果包括 'Set-Cookie' 响应头,该响应'不会'被缓存
2) proxy_ignore_headers
3) proxy_hide_header
思考: 哪些'响应头字符'是合法的
备注:'点'在ASCII中是46'2e',至少是'满足RFC规范'的
案例: 响应头'eg --> "Host "'带空格,nginx处理'报错'
+++++++++++ "细节点" +++++++++++
1) 204 '状态码' --> add_header 'always'
HTTP 204状态码含义: 请求已经被处理,但无返回内容'No Content',这里指的是'response body'
'204'的三个应用场景:
[1]、跨域==> 204 --> add_header 'always'
[2]、PUT、DELET进行'资源'更新 --> '元数据更新'
[3]、OPTIONS预检请求,正确['204'],错误['412']
备注:Range相关的206和416状态码
204(No-Content),服务器成功处理了请求,但不需要返回任何实体内容
3) 了解'常见报错'
重点理解各种Access-Control-Allow响应头以及跨域的报错
默认proxy_set_header Host $proxy_host导致跨域Cookie丢失
nginx 使用 proxy_cookie_path 解决反向代理 cookie 丢失导致无法登录等问题
思考:nginx利用cookie可以'做哪些操作'? --> 'map匹配'
场景:获取Cookie中的信息进行'限流'、'黑白'名单、'灰度'发布等
备注:后续'写一个专栏'
1) 不同'厂商'的浏览器,并且相同厂商的'不同版本'的浏览器,对Cookie的使用'有差异'
备注: 涉及Cookie的'存储'和'使用'
2) 后续关注
[1]、'CSRF'的机制
[2]、Cookie丢失的原因 --> "抓包分析"
1) 是指请求'没有携带'预期的Cookie
2) 还是js读取不到后端返回的Set-Cookie
[3]、session共享方案 --> memcached、tomcat自身的、redis、spring的集成方案
原文地址:https://blog.csdn.net/wzj_110/article/details/130354505
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.7code.cn/show_28410.html
如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!
声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。