浏览器何时发送 Origin 标头?浏览器何时将原点设置为空? [英] When do browsers send the Origin header? When do browsers set the origin to null?

查看：86
本文介绍了浏览器何时发送 Origin 标头?浏览器何时将原点设置为空?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

正如您从 这个 Bugzilla 线程(和 也)，Firefox 没有始终在 POST 请求中发送 Origin 标头.RFC 声明不应以某些未定义的隐私"发送-敏感"上下文.Mozilla 在此处定义了这些上下文.

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.

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

I'd like to know 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 Internet Explorer will), but I can't confirm that in the documentation. Is it enumerated somewhere that I'm missing?

推荐答案

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

As far as what the relevant specs actually require, the answer has a couple parts:

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

详情如下:

HTML 规范使用术语 opaque origin 并将其定义为内在价值":

The HTML spec uses the term opaque origin and defines it as an "internal value":

没有序列化，它可以从(它被序列化为空"每个原点的 ASCII 序列化)重新创建，唯一有意义的操作是测试是否相等

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

换句话说，HTML 规范在任何地方都说opaque origin，您可以将其转换为 null.

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

HTML 规范要求浏览器在这些情况下设置不透明来源或唯一来源:

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

  1. 跨源图像(包括跨源img元素)
  2. 跨源媒体数据(包括跨源video 和 audio 元素)
  3. 从 data: URL 生成的任何文档
  4. 任何带有沙箱的iframe不包含值 allow-same-origin
    5. 的 code> 属性
  5. 使用 createDocument() 等以编程方式创建的任何文档.
  6. 任何没有创建者浏览上下文的文档
  7. 网络错误响应
  8. 应该导航响应来自源中的导航请求类型目标被内容安全策略阻止? 算法在导航响应上执行时返回 Blocked
  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 规范要求浏览器将原点设置为全局唯一标识符"(这基本上与不透明原点"的含义相同，基本上意味着 null...):

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:

  1. 跨源重定向

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

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

  1. 对于blob: URL
  2. 对于 file: 网址
  3. 对于方案不是 http、https、ftp、ws、wss 或 gopher.
  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.

但请注意，仅仅因为浏览器在内部设置了一个不透明的原点——本质上是 null——并不一定意味着浏览器会发送一个 Origin 标头.因此，有关浏览器何时必须发送 Origin 标头的详细信息，请参阅此答案的下一部分.

But note 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 next part of this answer for details about when browsers must send the Origin header.

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

Browsers send the Origin header for cross-origin requests initiated by a fetch() or XHR call, or by an ajax method from a JavaScript library (axios, jQuery, etc.) — but not for normal page navigations (that is, when you open a web page directly in a browser), and not (normally) for resources embedded in a web page (for example, not for CSS stylesheets, scripts, or images).

但这种描述是一种简化.当浏览器发送 Origin 标头时，除了跨源 XHR/fetch/ajax 调用，还有浏览器为嵌入资源发送 Origin 标头的情况.那么下面是更长的答案.

But that description is a simplification. There are cases other than cross-origin XHR/fetch/ajax calls when browsers send the Origin header, and cases when browsers send the Origin header for embedded resources. So what follows below is the longer answer.

在规范要求方面:规范要求 Origin 标头仅针对 Fetch 规范定义为 CORS 请求:

In terms of the spec requirements: The spec requires the Origin header to be sent only for any request which the Fetch spec defines as a CORS request:

CORS 请求 是包含 Origin 标头的 HTTP 请求.它不能被可靠地识别为参与 CORS 协议，因为 Origin 标头 也包含在方法既不是 GET 也不是 HEAD.

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.

因此，规范的含义是:Origin 标头在所有跨域请求中发送，但它也始终为所有 POST<发送/code>、PUT、PATCH 和 DELETE 请求——即使对于 same-origin POST、PUT、PATCH 和 DELETE 请求(根据 Fetch 中的定义，它们实际上是CORS 请求"——即使它们是同源).＊

So, what the spec means there is: The Origin header is sent in all cross-origin requests, but it’s also always sent for all POST, PUT, PATCH, and DELETE requests — even for same-origin POST, PUT, PATCH, and DELETE requests (which by definition in Fetch are actually "CORS requests" — even though they’re same-origin).＊

浏览器必须发送 Origin 标头的其他情况是使用CORS 标志"设置发出请求的任何情况——就 HTTP(S) 请求而言，除非请求模式是navigate、websocket、same-origin 或 no-cors.

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 将模式设置为 cors.但是对于 Fetch API，您可以使用 fetch(...) 方法的 init-object 参数的 mode 字段设置这些请求模式:

XHR always sets the mode to cors. But with the Fetch API, those request modes are the ones you can 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

字体请求总是将模式设置为 cors，因此总是有 Origin 标头.

Font requests always have the mode set to cors and so always have the Origin header.

对于任何具有 crossorigin 属性的元素(又名CORS设置属性")，HTML规范要求浏览器将请求模式设置为cors(并发送Origin标题).

And 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).

否则，对于嵌入式资源——任何具有发起请求的 URL 属性的元素(

相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆