Permissions-Policy：deferred-fetch-minimal 指令
Limited availability
This feature is not Baseline because it does not work in some of the most widely-used browsers.
HTTP Permissions-Policy 标头的 deferred-fetch-minimal 指令属于 Fetch API。
此指令与 deferred-fetch 一起，决定了 640KiB 的总配额限制如何在顶级源及其跨源子框架之间分配。默认情况下，顶级源获得 512KiB，每个跨源子框架从剩余的 128KiB 中获得 8KiB。deferred-fetch-minimal 权限策略还可以阻止所有源；这将把 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 或 () 的顶级框架完全不允许跨源子框架使用默认的共享 128KiB 配额。相反，子框架的 128KiB 配额将计入其常规配额中。
默认策略
deferred-fetch-minimal 的默认允许列表是 *。
示例
更多示例，请参见 fetchLater() 配额。
用尽最小配额
http
Permissions-Policy: deferred-fetch=(self "https://b.com")
b.com的子框架在创建时从顶级域的 512KiB 配额中获得 64KiB 的配额。c.com的子框架未在列表中，因此在创建时从 128KiB 共享配额中获得 8KiB 的配额。- 另外 15 个子框架在创建时会获得 8KiB（类似于
c.com，另一个c.com子框架也会获得另一个 8KiB 的配额）。 - 下一个子框架将不会被授予任何配额。
- 如果其中一个子框架被移除，其延迟获取（fetch）将被发送。
- 下一个子框架将获得 8KiB 的配额，因为又有配额可用了。
完全撤销最小配额（有例外）
http
Permissions-Policy: deferred-fetch=(self "https://b.com")
Permissions-Policy: deferred-fetch-minimal=()
b.com的子框架在创建时获得 64KiB 的配额。c.com的子框架在创建时不会获得任何配额。- 顶级文档及其同源后代可以使用最多 640KiB 的配额，但如果创建了
b.com子框架，则会减少到 574KiB。
完全撤销最小配额（无例外）
http
Permissions-Policy: deferred-fetch-minimal=()
- 顶级文档及其同源后代可以使用最多 640KiB 的配额。
- 子框架不会被分配任何配额，无法使用
fetchLater()。
将最小配额限制为指定来源
http
Permissions-Policy: deferred-fetch=(self "https://b.com")
Permissions-Policy: deferred-fetch-minimal=("https://c.com")
b.com的子框架在创建时获得 64KiB 的配额。c.com的子框架在创建时获得 8KiB 的配额。d.com的子框架在创建时不会获得任何配额。
规范
| Specification |
|---|
| Fetch # available-deferred-fetch-quota |