背景知识铺垫
一 nginx中与cookie相关
① Cookie请求头内容回顾
cookie的形式和属性
② nginx获取cookie值的两种方法
1) $http_cookie -->获取Cookie请求头"所有值"
2) $COOKIE_flag -->获取Cookie请求头的"某个key"
[1]、'脱敏'场景在'日志'中只记录'非敏感'的key
[2]、由于nginx会进行'lowcase',将所有的字符转化为'小写',推荐使用$COOKIE_lowercase形式
3) nginx也可通过'map'获取指定的cookie
4) 理解了'Cookie'请求头的构成,就理解了'方法二'的正则
常见： 响应头中的'Cookie'头大,导致'400'报错client_header_buffer_size
相关参考
If the directive is specified on the server level,\
the value from the 'default server' can be used --> "如何理解"?
解读： 如果指令是在'server'级别指定,则仅server为'默认server'才使用'该指令'
off: 默认判定'请求头'无效
除了下划线,nginx还可能丢弃哪些请求头
重点： 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 headersproxy_cookie_xxx指令的深入了解
+++++++++ "(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响应头以及跨域的报错
Nginx通过Cookie做灰度就这么简单
默认proxy_set_header Host $proxy_host导致跨域Cookie丢失
nginx 使用 proxy_cookie_path 解决反向代理 cookie 丢失导致无法登录等问题
思考：nginx利用cookie可以'做哪些操作'? --> 'map匹配'
场景：获取Cookie中的信息进行'限流'、'黑白'名单、'灰度'发布等
备注：后续'写一个专栏'nginx发送一次请求的完整过程
⑥ Cookie浏览器使用的限制
1) 不同'厂商'的浏览器,并且相同厂商的'不同版本'的浏览器,对Cookie的使用'有差异'
备注： 涉及Cookie的'存储'和'使用'
2) 后续关注
[1]、'CSRF'的机制
[2]、Cookie丢失的原因 --> "抓包分析"
1) 是指请求'没有携带'预期的Cookie
2) 还是js读取不到后端返回的Set-Cookie
[3]、session共享方案 --> memcached、tomcat自身的、redis、spring的集成方案理解lua指令
