Firefox在POST请求中何时将Origin标头设置为null？ [英] When does Firefox set the Origin header to null in POST requests?

问题描述

正如您从这个Bugzilla主题（和 RFC 指出，不应以某种未定义的隐私敏感的背景下。 Mozilla在这里定义了这些上下文。

我想知道的是，这些是Firefox不会发送Origin头文件的唯一情况。据我可以告诉它也不会发送在交叉源POST请求（虽然Chrome和IE将），但我不能确认在文档中。它是枚举的地方，我失踪？

谢谢。

至于规格的要求，上面的问题需要分成几个答案：

• 当浏览器必须发送Origin头文件时


• 当浏览器必须在内部将origin设置为一个将被序列化为 null

我怀疑Firefox需要什么从规格）被列举。但是就列举 spec 的要求而言，在这里详尽地详细说明了两个部分： 当浏览器必须发送Origin头部

问题的答案当浏览器必须发送Origin头文件吗？是： Origin 标题只发送给Fetch规范定义为 CORS请求的任何请求 ： CORS请求是一个HTTP请求， c $ c> Origin 标题。它不能被可靠地识别为参与CORS协议，因为 Origin 标题也包含在所有请求中，它们的方法既不是 GET HEAD 。

Fetch规范中的实际语句，它要求浏览器发送 Origin 所有请求的头部都不是 GET 也不是 HEAD 是这样的：

如果设置了 CORS标志或者 httpRequest 方法既不是 GET HEAD ，然后追加 Origin / httpRequest 的来源，序列化和UTF- 8编码到httpRequest的头部列表。

因此，需要浏览器发送 Origin for all POST 请求，包括同源 POST 取实际上是CORS请求 - 尽管它们是同源的）。

---

注意：上面描述了Fetch规范当前如何定义需求，这是由于对于在2016-12-09进行了说明。直到那时，要求才有所不同：

• 以前没有 Origin 原产地


• 之前没有原产地是由< form>
b
以前的是必需的，但不是spec 当前要求的。



---





浏览器必须发送 Origin 头部的其他情况是，使用CORS标志设置请求的任何情况 - 就HTTP（S）请求而言 除请求模式 < navigate ， websocket ，同源或 no-cors 。


$ b XHR always 将模式设置为 CORS 。但是对于Fetch API，这些请求模式是你可以用 fetch（...）的init-object参数的 mode 字段设置的模式。 ）方法：



  fetch（http://example.com，{mode： no-cors'}）// no Origin将被发送
  

除此之外， 一个 crossorigin 属性 （ aka CORS设置属性），HTML规范要求浏览器将请求模式设置为 cors （并发送 no-cors ，这意味着没有 Origin 标题被发送。





因此，以上是有关浏览器发送 Origin 标题的细节。





答案的下一部分是关于何时将原始值设置为 null 。





当浏览器必须将origin设置为一个将被序列化为 null





与浏览器必须发送标头的要求分开时，浏览器必须将源设置为 null



HTML规范使用术语






一个内部值，其中没有序列化它可以被重新创建（它被序列化为null，每个ASCII序列化一个原点），为此唯一有意义的操作是测试相等性。


换句话说，无处不在的HTML规范说不透明的来源，你可以把它翻译成 null 。



HTML规范要求浏览器在以下情况下设置不透明的来源或唯一来源：




1. img 元素）


2. 跨媒体资料（包括跨越视频和音频元素）


3. 从 data： URL


4. 任何> iframe 与沙箱属性不包含值 allow-same-origin


5. 任何使用 createDocument（） code>等等


6. 任何没有创建者浏览上下文的文档 网络错误的回应


7. 内容安全策略是否应阻止对来自目标源的类型导航请求的导航响应算法返回在导航响应Fetch规范要求浏览器将原点设置为全局唯一标识符（这基本上意味着相同的东西）作为不透明的来源，基本上意味着 null ...）：
   
   
   
   
   8. 重定向到来源
   
   ol>
   
   

   在下列情况下，URL规范要求浏览器设置一个不透明的原点：
   
   

   
   
   9. blob：网址
   
   
   10. For file：网址
   
   
   11. 对于其他方案不是 http ， https ， ftp ， ws ， wss 或 gopher 。
   
   

   但重要的是要理解，因为浏览器内部设置一个不透明的来源 - 本质上是 null - 这并不意味着浏览器会发送一个 Origin 头。因此，请参阅此答案的第一部分，以获取有关浏览器何时必须发送 Origin 标头的详细信息。

   
   

   As you can see from this Bugzilla thread (and also), Firefox does not always send an Origin header in POST requests. The RFC states that it should not be sent in certain undefined "privacy-sensitive" contexts. Mozilla defines those contexts here.

   What I'd like to know is whether these are the only situations in which Firefox will not send the Origin header. As far as I can tell it also will not send it in cross-origin POST requests (though Chrome and IE will), but I can't confirm that in the documentation. Is it enumerated somewhere that I'm missing?

   Thanks.

   解决方案

   As far as what the specs require, the question above needs to be divided into a couple of answers:

   • When browsers must send the Origin header
   • When browsers must internally set origin to a value that’ll get serialized as null

   I’m doubt that what Firefox requires around this (where it’s different from the spec) is enumerated. But as far as enumerating the spec requirements, here they are, in exhaustive detail, in two parts:

   When browsers must send the Origin header

   The answer to the question When must browsers must send the Origin header? is: The Origin header is sent only for any request which the Fetch spec defines as a CORS request:

   A CORS request is an HTTP request that includes an Origin header. It cannot be reliably identified as participating in the CORS protocol as the Origin header is also included for all requests whose method is neither GET nor HEAD.

   The actual statement in the Fetch spec that requires browsers to send the Origin header for all requests whose method is neither GET nor HEAD is this:

   If the CORS flag is set or httpRequest’s method is neither GET nor HEAD, then append Origin/httpRequest’s origin, serialized and UTF-8 encoded, to httpRequest’s header list.

   So that requires browsers to send Origin for all POST requests, including same-origin POSTs (which by definition in Fetch are actually "CORS requests"—even though they’re same-origin).

   ---

   Note: The above describes how the Fetch spec currently defines the requirements, due to a change that was made to the spec on 2016-12-09. Up until then the requirements were different:

   • previously no Origin was sent for a same-origin POST
   • previously no Origin was sent for cross-origin POST from a <form> (without CORS)

   So I think the Firefox behavior described in the question conforms to what the spec previously required, but not what the spec currently requires.

   ---

   The other cases when browsers must send the Origin header are any cases where a request is made with the "CORS flag" set—which, as far as HTTP(S) requests is except when the request mode is navigate, websocket, same-origin, or no-cors.

   XHR always sets the mode to cors. But with the Fetch API, those request modes are the ones you can be set with the mode field of the init-object argument to the fetch(…) method:

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

   Along with that, for any element with a crossorigin attribute (aka "CORS setting attribute), the HTML spec requires browsers to set the request mode to cors (and to send the Origin header).

   Otherwise, for any elements that initiate requests (scripts, stylesheets, images, media elements), the mode for the requests defaults to no-cors, which means no Origin header is sent for them.

   So that above are the details about the conditions under which browsers send the Origin header.

   The next part of the answer is about when the origin value will be set to null.

   When browsers must set origin to a value that’ll get serialized as null

   Separate from requirements for when browsers must send the Origin header are requirements for when browsers must set an origin to null, which are defined in the following specs:

   The HTML spec uses the term opaque origin and says this:

   An internal value, with no serialization it can be recreated from (it is serialized as "null" per ASCII serialization of an origin), for which the only meaningful operation is testing for equality.

   In other words everywhere the HTML spec says opaque origin, you can translate that to null.

   The HTML spec requires browsers to set an opaque origin or unique origin in the following cases:

   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

   The Fetch spec requires browsers to set the origin to a "globally unique identifier" (which basically means the same thing as "opaque origin" which basically means null…) in one case:

   8. Redirects across origins

   The URL spec requires browsers to set an opaque origin in the following cases:

   9. For blob: URLs
   10. For file: URLs
   11. For any other URLs whose scheme is not one of http, https, ftp, ws, wss, or gopher.

   But it’s important to understand that just because the browser has internally set an opaque origin—essentially null—that doesn’t necessarily mean the browser will send an Origin header. So see the first part of this answer for details about when browsers must send the Origin header.

   这篇关于Firefox在POST请求中何时将Origin标头设置为null？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！