justdoit123

@zy445566
@tool2dx

先前实验下来的确有这个发现。浏览器对于当前 document 访问，是会忽略缓存相关的 Header 。即便我问的这个 `immutable` 也是会忽略的。

iframe 确实没实验过。感谢分享！

@sagaxu 你说的那是协商缓存吧？ Expires 与 Cache-Control max-age=XXX 是强缓存。

@bxb100 感谢～ 这个 Q&A 说得很清楚。

@lovelylain 浏览器为了向后兼容，依然允许表单构建的请求进行跨域。而表单请求只有 GET/POST 两种 method 。这种请求，是有办法自动带上目标网站的 Cookie 的，从而实现 CSRF 攻击。

我认为是可以的。如果请求允许 PUT ，那么就无法在浏览器端构建出 CSRF 攻击。

但是，这种防御方式有点自损八百的感觉。

另外，我心中也有一个疑惑，为什么有的人要把 CSRF token 存放到 session 里？我感觉这种绑定的意义不大，还增加服务的负担。

不用讨论这样做 CORS 。我只是读文档，有疑惑而已。

楼上 #1, #6 说的是正解，非常感谢~ 意思就是说，简单请求 **只是** 不触发预检，并不是说这类请求能绕过 CORS 保护。

而 script 、img 、link 、form 这类标签构造出来的请求能绕过 CORS 保护，是为了 **向后兼容**。

太正常了。

web 环境跟 server 环境经常混为一谈。狭义一点的 web 环境，应该是指浏览器环境。 但是 http server 不是只服务于浏览器。

经典的几个莫名其妙的问题以及神奇操作。

1. cookie 与 session 有什么区别？二者不是之间替代品，没什么好比较。
2. cookie 与 jwt token 有什么区别？二者不是之间替代品，没什么好比较。
3. 在浏览器环境，把 jwt token 塞 Authentication header 里。那请问你的 jwt token 不是需要让 js 访问吗？那不是等于会泄露在某处？
4. 把公开的 API 加上 CSRF 保护。这类 API ，一般会用服务于 sdk 、app 、server 2 server ，这种场景下防什么 CSRF 攻击。CSRF 攻击只在浏览器发生。server 可以分流，身份信息 放在 cookie 里的，是浏览器流量，需要 CSRF 保护，放在 Authentication header 里的，是一些非浏览器流量，不需要 CSRF 保护。
...

GraphQL 之前的项目用过。现在接一些第三方服务也会用到。反正还是喜欢不起来，感觉国外比较受欢迎。

我不喜欢大概有两点：
1. 引入新的 DSL 。我觉得 API 对接还没到需要引入一个 DSL 的地步，围绕着这个 DSL 有好多生态要搭建，做不好体验就比较差。写 query 时的字段补全、嵌套 format 等等问题。感觉体验不太好。
2. 容易写成一个臃肿的请求。