代码之家  ›  专栏  ›  技术社区  ›  Qiulang

为什么没有为我的明显的跨来源请求添加来源请求标头?

  •  0
  • Qiulang  · 技术社区  · 4 年前

    你可以从中看到 this Bugzilla thread (及 also ),Firefox并不总是在POST请求中发送源标题。 The RFC 声明不应在某些未定义的“隐私敏感”上下文中发送。Mozilla定义了这些上下文 here .

    我想知道Firefox是否只有在这些情况下才会发送Origin头。据我所知,它也不会在跨源POST请求中发送它(尽管Chrome和Internet Explorer会),但我无法在文档中确认这一点。是不是列举了我遗漏的地方?

    0 回复  |  直到 4 年前
        1
  •  83
  •   sideshowbarker    5 年前

    就相关规范的实际要求而言,答案有两个部分:

    • 当浏览器必须在内部将原点设置为将被序列化为 null
    • 浏览器必须发送源标题时

    详情如下:

    当浏览器必须将origin设置为一个值,该值将被序列化为 无效的

    HTML规范使用了这个术语 opaque origin 并将其定义为内部值:

    没有序列化,它可以从中重新创建( 它被序列化为“null” 每ASCII序列化一次),唯一有意义的操作是测试是否相等

    换句话说,HTML规范所说的每一个地方 不透明原点 ,你可以把它翻译成 无效的 .

    HTML规范要求浏览器在以下情况下设置不透明原点或唯一原点:

    1. Cross-origin images (including cross-origin img elements)
    2. Cross-origin media data (including cross-origin video and audio elements)
    3. Any document generated from a data: URL
    4. Any iframe with a sandbox attribute that doesn’t contain the value allow-same-origin
    5. Any document programmatically created using createDocument() , etc.
    6. Any document that does not have a creator browsing context
    7. Responses that are network errors
    8. The Should navigation response to navigation request of type from source in target be blocked by Content Security Policy? algorithm returns Blocked when executed on a navigate response

    Fetch规范要求浏览器将原点设置为全局唯一标识符(这基本上与不透明原点的意思相同,不透明原点的意思基本上是 无效的 )在一个案例中:

    1. Redirects across origins

    URL规范要求浏览器在以下情况下设置不透明原点:

    1. For blob: URLs
    2. For file: URLs
    3. For any other URLs whose scheme is not one of http , https , ftp , ws , wss , or gopher .

    但请注意,仅仅因为浏览器在本质上设置了不透明的源代码 无效的 这并不一定意味着浏览器会发送 Origin 头球。因此,请参阅本答案的下一部分,了解浏览器何时必须发送 起源 头球。


    浏览器必须发送源标题时

    浏览器发送 起源 由服务器发起的跨源请求的标头 fetch() 或XHR调用,或通过JavaScript库(axios、jQuery等)中的ajax方法,但不适用于正常的页面导航(即,当您直接在浏览器中打开网页时),也不适用于(通常)嵌入网页中的资源(例如,不适用于CSS样式表、脚本或图像)。

    但这种描述是一种简化。除了跨源XHR/fetch/ajax调用之外,浏览器发送 起源 标题,以及浏览器发送 起源 嵌入式资源的标题。下面是一个较长的答案。


    在规范要求方面:规范要求 起源 仅针对Fetch规范定义为 CORS request :

    A. CORS请求 是包含 起源 头球。无法可靠地确定其作为 起源 标题 对于方法既不是 GET 也没有 HEAD .

    所以,规范的意思是: 起源 在所有跨来源请求中发送标头, 但是 它也总是发送给所有人 POST , PUT , PATCH DELETE 甚至要求 同源 邮递 , , 色斑 删去 请求(根据Fetch中的定义,这些请求实际上是CORS请求,尽管它们的来源相同)。


    浏览器必须发送 起源 header是使用CORS标志集发出请求的任何情况,就HTTP(S)请求而言,CORS标志集是 except when the request mode is navigate , websocket , same-origin , or no-cors .

    XHR 总是 将模式设置为 cors .但使用Fetch API,这些请求模式是可以使用 mode 函数的init对象参数的字段 fetch(…) 方法:

    fetch("http://example.com", { mode: 'no-cors' }) // no Origin will be sent
    

    字体请求总是将模式设置为 科尔斯 所以总是有 起源 头球。

    对于任何带有 a crossorigin attribute ( 又称作 HTML规范要求浏览器将请求模式设置为 科尔斯 (并发送 起源 标题)。

    否则,对于嵌入式资源——任何具有启动请求的URL属性的元素( <script src> ,样式表,图像,媒体元素)请求的模式默认为 没有cors ; 既然这些要求 收到 请求,也就是说,根据规范,浏览器不会发送任何请求 起源 他们的头球。

    当HTML表单元素启动时 邮递 请求,这些请求的模式 邮递 s也默认为 没有cors 与嵌入式资源的默认模式相同 没有cors .然而,与 没有cors 模式 收到 对于嵌入式资源的请求,浏览器会发送 起源 头球 没有cors 模式 邮递 从HTML表单元素开始。

    原因是,正如本答案前面提到的,浏览器总是发送 起源 总头球 邮递 , , 色斑 删去 请求。

    此外,为了完整性和明确起见:对于导航,浏览器不发送 起源 头球。也就是说,如果用户通过将URL粘贴到浏览器地址栏或通过跟踪另一个web文档的链接直接导航到资源,那么浏览器不会发送任何消息 起源 头球。


    * 这个 algorithm in the Fetch spec 这需要浏览器发送 起源 所有CORS请求的标题如下:

    附加请求 起源 标题,给出一个请求 要求 ,运行以下步骤:

    1.让我们 多里金 是用字节序列化请求源的结果 要求 .
    2.如果 要求 中国的反应是“污染” 科尔斯 “或者 要求 s模式是“ 网袋 “那么
    追加 起源 / 多里金 要求 标题列表。
    3.否则,如果 要求 }}s方法既不是 收到 也没有 ,
    然后: [同时发送 起源 在这种情况下,标题也是]

    第二步需要 起源 要在所有跨源请求中发送的标头,因为所有跨源请求的响应污染设置为“ 科尔斯 ".

    但第三步需要 起源 标题也要发送到 同源 邮递 , , 色斑 删去 请求(根据Fetch中的定义,这些请求实际上是CORS请求,尽管它们的来源相同)。

    上面描述了Fetch规范目前如何定义需求,因为 change that was made to the spec on 2016-12-09 .在那之前,要求是不同的:

      以前没有 起源 被派往同一个地方
      以前没有 起源 是从一个 <form> (不含CORS)

    因此,问题描述的Firefox行为是规范的内容 先前 必需的,不是什么 目前 要求。

        2
  •  1
  •   andrewdotn    4 年前

    对我来说,这是发生在一个超级标准的表单帖子上,在localhost上的一个相对URL上,似乎是由

    <meta name="referrer" content="no-referrer">
    

    <head> .

    改成

    <meta name="referrer" content="same-origin">
    

    似乎让Firefox更快乐。