Permissions-Policy: deferred-fetch-minimal 指令

可用性有限

此特性不是基线特性,因为它在一些最广泛使用的浏览器中不起作用。

实验性: 这是一项实验性技术
在生产中使用此技术之前,请仔细检查浏览器兼容性表格

deferred-fetch-minimal Permissions-Policy 指令是 fetchLater() API 的一部分。

此指令与 deferred-fetch 一起,决定了 640KiB 的总配额限制如何在顶级源及其跨源子帧之间分配。默认情况下,顶级源被授予 512KiB,每个跨源子帧从剩余的 128KiB 中获得 8KiB。deferred-fetch-minimal Permissions Policy 也可以阻止所有源;这将把 128KiB 的共享限制重新分配给顶级配额,使其可以访问完整的 640KiB 限制。

有关更多详细信息和示例,请参阅 fetchLater() 配额指南。

语法

http
Permissions-policy: deferred-fetch-minimal=*
Permissions-policy: deferred-fetch-minimal=()
Permissions-policy: deferred-fetch-minimal=(self)
Permissions-policy: deferred-fetch-minimal=(<url-list>)
<url-list>

一个用空格分隔的源列表,这些源被允许使用次级 128KiB 配额(每个子帧最大 8KiB)。

如果顶级帧的 deferred-fetch-minimal 权限设置为 self(),则不允许跨源子帧使用默认的共享 128kb 配额。相反,子帧的 128KiB 配额会添加到其正常配额中。

默认策略

deferred-fetch-minimal 的默认允许列表是 *

示例

有关更多示例,请参阅 fetchLater() 配额

使用最小配额

http
Permissions-Policy: deferred-fetch=(self "https://b.com")
  1. b.com 的子帧在创建时从顶级 512KiB 限制中获得 64KiB。
  2. c.com 的子帧未列出,因此在创建时从 128KiB 共享限制中获得 8KiB。
  3. 另外 15 个子帧在创建时将获得 8KiB(类似于 c.com,另一个 c.com 子帧也将获得另一个 8KiB 配额)。
  4. 下一个子帧将不会获得任何配额。
  5. 如果其中一个子帧被移除,其延迟获取将被发送。
  6. 下一个子帧将获得 8KiB 配额,因为再次有可用配额。

完全撤销最小配额(有例外)

http
Permissions-Policy: deferred-fetch=(self "https://b.com")
Permissions-Policy: deferred-fetch-minimal=()
  1. b.com 的子帧在创建时获得 64KiB。
  2. c.com 的子帧在创建时未获得任何配额。
  3. 顶级文档及其同源后代最多可以使用完整的 640KiB,但如果创建了 b.com 子帧,则会减少到 574KiB。

完全撤销最小配额(无例外)

http
Permissions-Policy: deferred-fetch-minimal=()
  1. 顶级文档及其同源后代可以使用完整的 640KiB。
  2. 子帧未分配任何配额,也不能使用 fetchLater()

将最小配额限制为指定源

http
Permissions-Policy: deferred-fetch=(self "https://b.com")
Permissions-Policy: deferred-fetch-minimal=("https://c.com")
  1. b.com 的子帧在创建时获得 64KiB。
  2. c.com 的子帧在创建时获得 8KiB。
  3. d.com 的子帧在创建时未获得任何配额。

规范

规范
Fetch
# available-deferred-fetch-quota

浏览器兼容性

另见