乐趣区

关于javascript:CrossOrigin-Read-Blocking-CORB-网络兼容性和对其他资源的影响问题

jiezi

CORB 对图像的影响

CORB 对标签应该没有显著的影响<img>，除非图像资源 1) 被谬误地标记为不正确的、非图像的、受 CORB 爱护的 Content-Type 和 2) 与响应标头一起提供X-Content-Type-Options: nosniff。

例子：

  • 正确标记的 HTML 文档

    • 标签中应用的资源<img>：

      • 注释：一个 HTML 文档
      • Content-Type: text/html
      • 没有 X-Content-Type-Options 题目
    • 预期行为：无显著差别。当 1) 尝试将 html 文档出现为图像（没有 CORB）和 2) 尝试将空响应出现为图像（当 CORB 阻止响应时）时，出现的图像应该是雷同的损坏图像。
    • WPT 测试：fetch/corb/img-html-correctly-labeled.sub.html

  • 谬误标记的图像（嗅探）

    • 标签中应用的资源<img>：

      • 注释：图像
      • Content-Type: text/html
      • 没有 X-Content-Type-Options 题目
    • 预期行为：无差别 。CORB 将嗅探到响应主体实际上 不是 受 CORB 爱护的类型，因而将容许响应。
    • WPT 测试：fetch/corb/img-png-mislabeled-as-html.sub.html

  • 谬误标记的图像（nosniff）

    • 标签中应用的资源<img>：

      • 注释：图像
      • Content-Type: text/html
      • X-Content-Type-Options: nosniff
    • 预期行为：可察看到的差别 。因为nosniff 标头，CORB 将不得不依赖 Content-Type 标头。因为此响应被谬误标记（注释是图像，但题目 Content-Type 说它是 html 文档），CORB 将谬误地将响应分类为须要 CORB 爱护。
    • WPT 测试：fetch/corb/img-png-mislabeled-as-html-nosniff.tentative.sub.html

除了 HTML<img>标记之外，下面的示例还实用于其余应用图像的网络性能 – 包含但不限于：

  • /favicon.ico
  • SVG 的<image>，
  • <link rel="preload" as="image" ...>（参见 WPT 测试fetch/corb/preload-image-png-mislabeled-as-html-nosniff.tentative.sub.html：）
  • background-image在样式表中
  • 将图像绘制到（可能被净化的）HTML 上<canvas>

[lukasza@chromium.org] 晚期尝试阻止具备不兼容 MIME 类型的 nosniff 图像失败了。咱们认为 CORB 会更侥幸，因为它只会阻止 CORB 爱护的 MIME 类型的子集（例如，它不会 application/octet-stream 像 Firefox 谬误中援用的那样阻止）

CORB 对多媒体的影响

音频和视频资源应该会看到与图像相似的影响，只管 206 响应更有可能呈现在媒体上。

CORB 对脚本的影响

CORB 应该对标签没有显著的影响<script>，除非将标有正确 MIME 类型的受 CORB 爱护的非 JavaScript 资源作为脚本加载 – 在这些状况下，资源通常会导致语法错误，但受 CORB 爱护响应的空主体不会导致谬误。

例子：

  • 正确标记的 HTML 文档

    • 标签中应用的资源 <script>：

      • 注释：一个 HTML 文档
      • Content-Type: text/html
      • 没有 X-Content-Type-Options 题目
    • 预期行为：通过 GlobalEventHandlers.onerror可察看到的差别。大多数受 CORB 爱护的资源在解析为 JavaScript 时会导致语法错误。在 CORB 阻止响应后语法错误隐没，因为被阻止响应的空主体能够像 JavaScript 一样失常解析。
    • WPT 测试：fetch/corb/script-html-correctly-labeled.tentative.sub.html

[lukasza@chromium.org] 实践上，在 CORB 阻塞响应中应用非空响应可能会从新引入失落的语法错误。咱们没有走那条路，因为

  1. 应用非空响应将与 Fetch 标准的其余局部不统一（如不通明过滤响应）。
  2. 保留语法错误的存在可能须要更改 CORB 阻塞的响应主体的内容，具体取决于原始响应主体是否会导致语法错误。这会减少额定的复杂性，这对于 CORB 实现者和 Web 开发人员来说仿佛都是不可取的。

  • 谬误标记的脚本（嗅探）

    • 标签中应用的资源<script>：

      • 注释：适当的 JavaScript 脚本
      • Content-Type: text/html
      • 没有 X-Content-Type-Options 题目
    • 预期行为：无差别 。CORB 将嗅探到响应主体实际上 不是 受 CORB 爱护的类型，因而将容许响应。请留神，CORB 嗅探对于某些语法元素在 HTML 和 JavaScript 之间共享这一事实具备弹性（例如 comments）。
    • WPT 测试：fetch/corb/script-js-mislabeled-as-html.sub.html

  • 谬误标记的脚本（nosniff）

    • 标签中应用的资源 <script>：

      • 注释：适当的 JavaScript 脚本
      • Content-Type: text/html
      • X-Content-Type-Options: nosniff
    • 预期行为：无显著差别 。无论有没有 CORB，脚本都不会执行，因为当响应头响应的 MIME 类型（在示例中）不是 JavaScript MIME 类型nosniff 时，响应将导致响应被阻塞（Fetch 标准要求此行为）。text/html
    • WPT 测试：fetch/corb/script-js-mislabeled-as-html-nosniff.sub.html

除了 HTML<script>标记之外，下面的示例还实用于其余应用 JavaScript 的网络性能，包含相似脚本的指标，如 importScripts()、navigator.serviceWorker.register()、audioWorklet.addModule() 等。

CORB 对样式表的影响

CORB 对样式表应该没有显著的影响。

例子：

  • 任何未标记为文本 /css 的内容

    • 标签中应用的资源示例<link rel="stylesheet" href="...">：

      • 注释：一个 HTML 文档或一个简略无效的样式表或一个多语言 HTML/CSS 样式表
      • Content-Type: text/html
      • 没有 X-Content-Type-Options 题目
    • 预期行为：无显著差别 。即便没有 CORB，这样的款式示意例也会被回绝，因为因为 CSS 宽松的语法规定，跨源 CSS 须要正确的 Content-Type 标头（限度因浏览器而异：IE.aspx)、Firefox、Chrome、Safari（向下滚动到 CVE -2010-0051) 和歌剧)。此行为蕴含在 HTML 标准text/css 中，其中 1) 如果嵌入样式表的文档已设置为怪癖模式并且具备雷同的起源，则仅要求采纳 Content-Type，并且 2) 仅要求运行创立 CSS 样式表的步骤如果获取的资源的 Content-Type 是text/css.
    • WPT 测试：fetch/corb/style-css-mislabeled-as-html.sub.html,fetch/corb/style-html-correctly-labeled.sub.html

  • 任何未标记为文本 /css 的内容（nosniff）

    • 标签中应用的资源 <link rel="stylesheet" href="...">：

      • 注释：一个简略的样式表
      • Content-Type: text/html
      • X-Content-Type-Options: nosniff
    • 预期行为：无显著差别 。应用和不应用 CORB，样式表都不会加载，因为响应标头响应将导致响应在其 MIME 类型（在示例中）不是（Fetch 标准要求此行为）nosniff 时被阻止。text/html`text/css`
    • WPT 测试：fetch/corb/style-css-mislabeled-as-html-nosniff.sub.html

  • 带有 JSON 平安前缀的正确标记的样式表

    • 标签中应用的资源<link rel="stylesheet" href="...">：

      • 注释：以 JSON 平安前缀结尾的样式表
      • Content-Type: text/css
      • 没有 X-Content-Type-Options 题目
    • 预期行为：没有区别，因为对于标记为 的响应，不会执行 CORB 嗅探 JSON 平安前缀Content-Type: text/css。
    • WPT 测试：fetch/corb/style-css-with-json-parser-breaker.sub.html

CORB 对其余网络平台性能的影响

CORB 对以下场景没有影响：

  • XHR 和 fetch()

    • CORB 没有显著的影响，因为 XHR 和 fetch()曾经对响应利用了同源策略（例如，CORB 应该只阻止因为短少 CORS 而导致跨源 XHR 谬误的响应）。

  • 预取

    • CORB 阻止响应主体达到跨源渲染器，但 CORB 不会阻止响应主体被浏览器过程缓存（并随后传递到另一个同源渲染器过程）。

  • 跟踪和报告

    • 各种技术试图通过触发对记录用户拜访的 HTTP 服务器的 Web 申请来检查用户是否拜访了某些内容。Web 申请常常由 imgHTTP URI 的不可见元素触发，通常应用 204 或简短的 HTML 文档进行回复。除了img 标签之外，网站还能够应用 style 和script其余标签来跟踪应用状况。
    • CORB 不会影响这些技术，因为它们不依赖于 HTTP 服务器返回的理论内容。这也实用于其余不关怀响应的网络性能：信标、ping、CSP 违规报告等。

  • 服务人员

    • Service Worker 能够拦挡跨域申请并在 Service Worker中 人为地构建响应（即不跨域和 / 或平安边界）。CORB 不会阻止此类响应。
    • 当 service worker 缓存理论的跨源响应时（例如，在“no-cors”申请模式下），响应是“不通明的”，因而 CORB 能够在不扭转 service worker 的行为的状况下阻止此类响应（“不通明”响应具备不可拜访的体甚至没有 CORB）。

  • Blob 和文件 API

    • 即便没有 CORB，获取跨源 blob URL 也会被阻止（请参阅 https://github.com/whatwg/fetch/issues/666）。
    • WPT 测试：（script-html-via-cross-origin-blob-url.sub.html以及此处提交所涵盖的导航申请测试）。

  • 内容脚本和插件

    • CORB 不包含这些——CORB 假设适当的安全策略由内容脚本和插件的某些其余机制强制执行（例如，Adobe Flash 通过 crossdomain.xml 实现相似 CORS 的机制）。

量化 CORB 对现有网站的影响

CORB 已在可选的站点隔离模式和现场试验中启用，并且 Chromium 已被用来计算有多少合乎 CORB 条件的响应被阻止。（合乎 CORB 条件的响应不包含导航申请和下载；请参阅上文“哪些类型的申请合乎 CORB 条件？”局部。）咱们对 2018 年 2 月 Chrome Canary 的初始数据的剖析显示案例数量的下限较低对网页可见，并有可能进一步升高界线。

总体而言，所有合乎 CORB 条件的响应中有 0.961% 被阻止。 然而，其中超过一半曾经是空响应（即，实际上有一个 Content-Length: 0 响应标头），因而实际上不会导致行为扭转（即，只有非平安列表的标头会受到影响）。请留神，如果省略嗅探，简直 20% 的响应将被阻止，因而嗅探显然是必要的。

仔细观察，所有合乎 CORB 条件的响应中有 0.456% 是非空和阻塞的。 然而，这些状况中的大多数都属于下面大节中形容的不可察看的类别，例如将 HTML 响应作为跟踪像素传递给图像标签。

咱们能够关注两组可能具备显著影响的碰壁响应。

  • 因为 nosniff 标头或范畴申请，0.115% 的合乎 CORB 条件的响应可能已被显著阻止。

    这特定于状态代码不是 204 的非空响应，申请的上下文不会以其余形式疏忽谬误标记的 nosniff 内容（例如，作为脚本标签）。在这个组内：

    • 其中 95.16% 是标记为图像标签申请的 HTML 的 nosniff 响应。这些被屏蔽并且可能蕴含实在图像。然而，咱们预计其中许多案例实际上蕴含 HTML，并且无论如何都不会在图像标签中出现（正如咱们在一个案例中察看到的那样）。

[creis@chromium.org] 咱们正在思考通过嗅探这些响应来进一步升高这个界线，以确认有多少可能蕴含理论图像。

  • 另外 3.76% 是来自媒体上下文的文本 / 纯文本范畴申请。咱们尚未在实践中找到示例，但咱们正在思考容许对 text/plain 的范畴申请响应以防止此处中断。
  • 所有合乎 CORB 条件的响应中有 0.014% 是对脚本标签的有效输出，因为 CORB 嗅探显示它们是 HTML、XML 或 JSON。同样，这特定于没有 204 状态代码的非空响应。这些案例在实践中应该具备最小的中断危险（例如，超过一半具备谬误状态代码并且可能示意断开的链接），但在技术上能够依据是否报告语法错误来察看差别。

这些受影响案例的数量非常少，表明从 Web 兼容性的角度来看，CORB 很有前途。

退出移动版