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

85次阅读

共计 5353 个字符,预计需要花费 14 分钟才能阅读完成。

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 标签之外,网站还能够应用 stylescript其余标签来跟踪应用状况。
    • 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 很有前途。

正文完
 0