由于浏览器设置的标头,Safari拒绝重定向的CORS请求

Question

摘要

Safari拒绝一些涉及重定向的CORS请求,声称不允许某些标头.但是这个标题从未被脚本请求,但是由浏览器添加,所以我认为它应该没关系.

• Safari的行为是一个bug,
• 是否有规格问题,或
• 事情是这样的吗？

错误表示CORS中不允许某些标头

我观察到Safari似乎比其他浏览器更严格地解释CORS协议的情况.它使用错误消息拒绝某些请求

[错误]未能加载资源:请求头字段...不被允许Access-Control-Allow-Headers.

我已经在头字段中看到了这个Accept-Encoding,并且在将该字段添加到Access-Control-Allow-Headers相同的错误之后重复了DNT.包括在其他领域Access-Control-Request-Headers的预检要求的名单是Cache-Control,Origin和Accept-Language.

据我所知,这只会影响重定向的请求.如果我设法立即命名最终位置,请求成功.

WHATWG XHR:请求应该没有作者设置标头

我XMLHttpRequest在自己的代码中创建了它,没有任何库或框架干扰它.我绝对肯定我从来没有打电话给这个setRequestHeader()方法.

根据WHATWG XHR规范,我将假设我的作者请求标题列表应为空.该请求部分状态:

在笔者请求头是一个最初为空的头列表.

我可以在文档中读到非空参数send()可能Content-Type作为作者请求标题触发,但即使使用这样的无参数调用我也遇到了问题.

W3C CORS:只有作者设置的标题才有意义

在W3C推荐CORS描述的Access-Control-Request-Headers现场成由笔者请求头:

如果作者请求标题不为空,则包含Access-Control-Request-Headers带有标题字段值的标题,以字典顺序排列作者请求标题中的标题字段名称的逗号分隔列表,每个标题转换为ASCII小写(即使一个或多个是简单标题).

根据该规范,我可以看到错误的可能原因是:

如果每个头的字段名作者请求头是不是一个ASCII不区分大小写在报头字段名称之一匹配标题和标题是不是一个简单的报头,应用缓存和网络错误的步骤.

WHATWG Fetch从XHR获取列表

也许W3C CORS建议是错误的地方.也许它已被WHATWG Fetch生活标准所取代？这写在关于CORS-preflight fetch的部分中

3. 让头是名称的请求的头列表的标题,不包括CORS-safelisted请求头和重复,字典顺序排序,字节小写.

4. 设value为标题中彼此相隔0x2C的项.

5. 在预检的标题列表中设置Access-Control-Request-Headers为值.

那么这里的标题列表是什么？生活水平之间的连接XHR和抓取似乎是该send()方法规范.

6. 让req成为新请求,初始化如下:

   • 方法: 请求方法
   • url: 请求网址
   • 标题列表: 作者请求标题
   • unsafe-request标志:设置.
   • [...]

因此它将作者请求标题(根据我上面的考虑应该为空)绑定到标题列表,该标题列表用于构建所请求标题的列表.至少最初.

标题可能会被添加

当然,Fetch规范很长,并且在许多地方提到术语"标题列表" .很可能在那里某处有一些条款要求添加某些标题字段.但我认为没有任何部分在哪里Accept-Encoding或DNT明确地被提及作为预期的补充.它们被列为禁止标题,作者应该无法控制.

但是,HTTP-network-or-cache fetch部分中的以下文本在注释中提到它们:

13. 根据HTTP 修改httpRequest的标头列表.

    注意:如果我们能以某种方式使其更具规范性,那将是很棒的.此时头如Accept-Encoding,Connection,DNT,和Host,将被所附如果必要的话.

    Accept,Accept-Charset以及Accept-Language不能包含在这一点上.

    注意:Accept并且Accept-Language已经包含(除非fetch()使用,默认情况下不包括后者),并且Accept-Charset是浪费字节.有关详细信息,请参阅HTTP标头图层分区.

我发现很难判断这种添加的范围.除了auther指定的那些之外,这是"为每个HTTP添加标头"是为CORS考虑额外标头的原因吗？但为什么只有重定向？该HTTP重定向取部分没有提及添加更多的标头请求头的列表.

观察到的行为会很糟糕

如果我观察到的行为符合规范,那么我主要担心的是它本质上会阻止添加新的有用的HTTP头.您永远不会知道哪些网站可能会突然被破坏,因为浏览器不仅会添加它们,还会将它们包含在CORS检查中.另一方面,只考虑作者创建的脚本,将请求创建库与服务器实现相匹配就足够了,不用担心浏览器会做什么.对我来说听起来更安全.

题

所以我重复我的主要问题:

• Safari的行为是一个bug,
• 是否有规格问题,或
• 事情是这样的吗？

解决方法

对于一台服务器,我刚刚通过配置我的Apache来返回所有标头来解决这个问题,但这更像是一种解决方法.我想真正理解Safari在这里做什么,以及为什么.

交叉链接

SO上有几个问题表明Safari在CORS和重定向的组合方面存在问题:

• Safari Ajax cors请求不遵循重定向(2013)
  接受的答案指出"Apple声称这是HTML规范的编写方式"而未引用来源.听起来像Webkit bug 112471评论2,除了答案早于评论.

• 重定向后,HTML5 CORS请求在safari中失败(2014)
  接受的自我回答建议服务器辅助的解决方法.

• 在302重定向后,Safari失败了CORS请求(2015)未
  接受的回答提到了webkit bug 98838(未经证实),这反过来又暗示了错误112471(最近修复).那个人在某些时候也提到了标题为"CORS应该只处理脚本作者设置的请求标题"的错误63460,但似乎没有就此达成明确的共识.在结束时,DNT旗帜被明确命名.

• 在302重定向(2015)
  未答复后,Safari将简单Cors请求转换为预检.

右侧的类似问题清单可能会提供进一步的信息.

Answer 1

如果您下次分开提问可能会有所帮助。

• WHATWG Fetch 确实废弃了 CORS（它定义了 CORS 内联）。
• CORS 仅关注在网络级别之前设置的标头（基本上仅在 API 级别设置的标头）。其中一些可以由浏览器设置，例如，Accept但我想不出会影响 CORS 的设置。

所以，是的，我认为 Safari 有一个错误，但他们最近在这方面做出了改变，所以 WebKit nightlies 或 Safari Technology Preview 可能会做得更好。