跳到主要内容

4. 优先级参数 (Priority Parameters)

优先级信息是一系列键值对, 为未来扩展留出空间. 每个键值对表示一个优先级参数.

Priority HTTP header field (Section 5) 是在发出请求或响应时传输这组优先级参数的一种端到端方式. 客户端发送请求后, 可以通过发送 Sections 7.1 和 7.2 中定义的 HTTP 版本特定 PRIORITY_UPDATE frames, 改变它对响应优先级的看法 (Section 6). Frame 只在单个 hop 上传输优先级参数.

中介可以消费并生成 PRIORITY_UPDATE frame 或 Priority header field 中的优先级信号. 仅将 Priority request header field 传递给下一跳的中介会保留来自客户端的原始端到端信号; 见 Section 14. 中介可以传递 Priority header field, 并额外发送 PRIORITY_UPDATE frame. 这样做的效果是保留原始客户端端到端信号, 同时根据 Section 7 中的指导指示下一跳使用不同优先级. 替换或添加 Priority request header field 的中介会覆盖原始客户端端到端信号, 这可能影响该请求后续所有接收方的优先级处理.

对于 Priority header field 和 PRIORITY_UPDATE frame, 优先级参数集合都编码为 Dictionary (见 [STRUCTURED-FIELDS] 的 Section 3.2).

本文档定义 urgency (u) 和 incremental (i) 优先级参数. 当收到未携带这些优先级参数的 HTTP 请求时, 服务器 SHOULD 按照已指定其默认值的方式处理.

中介可以合并它转发的请求和响应中的信号. 注意, 响应中省略优先级参数的处理方式不同于请求中省略优先级参数的处理方式; 见 Section 8.

接收方按照 [STRUCTURED-FIELDS] 的 Section 4.2 所述解析 Dictionary. 如果 Dictionary 成功解析, 本文档额外要求: 未知优先级参数, 值超出范围的优先级参数, 或类型不符合预期的值 MUST 被忽略.

4.1. 紧急度 (Urgency)​

urgency (u) 参数值是 Integer (见 [STRUCTURED-FIELDS] 的 Section 3.3.1), 取值范围为 0 到 7 (含边界), 按优先级降序排列. 默认值为 3.

端点使用该参数传达它们对 HTTP 响应优先顺序 (precedence) 的看法. 选择的 urgency 值可以基于这样一种预期: 服务器可能使用此信息按紧急度顺序传输 HTTP 响应. 值越小, 优先顺序越高.

以下示例展示了一个请求 CSS 文件且 urgency 设置为 0 的请求:

:method = GET
:scheme = https
:authority = example.net
:path = /style.css
priority = u=0

如果客户端获取的文档很可能由多个 HTTP 资源组成 (例如 HTML), 它 SHOULD 为主资源分配默认 urgency 级别. 该约定允许服务器使用网站特定知识来细化 urgency (见 Section 8).

最低 urgency 级别 (7) 保留给后台任务, 例如交付软件更新. 该 urgency 级别 SHOULD NOT 用于获取会对用户交互产生任何影响的响应.

4.2. 增量式 (Incremental)​

incremental (i) 参数值是 Boolean (见 [STRUCTURED-FIELDS] 的 Section 3.3.6). 它表示 HTTP 响应是否可以增量式处理, 即随着响应分块到达而提供某些有意义的输出.

incremental 参数的默认值为 false (0).

如果客户端发出并发请求且 incremental 参数设置为 false, 并发提供具有相同 urgency 的响应没有收益, 因为客户端不会增量式处理这些响应. 对于具有相同 urgency 的非增量响应, 按这些请求生成的顺序逐个提供, 被认为是最佳策略.

如果客户端发出并发请求且 incremental 参数设置为 true, 并发提供具有相同 urgency 的请求可能有益. 这样做会分配连接带宽, 意味着响应需要更长时间才能完成. 当多个部分响应可能在完整响应可用之前为客户端提供某些价值时, 增量交付最有用.

以下示例展示了一个请求 JPEG 文件且 urgency 参数设置为 5, incremental 参数设置为 true 的请求.

:method = GET
:scheme = https
:authority = example.net
:path = /image.jpg
priority = u=5, i

4.3. 定义新的优先级参数 (Defining New Priority Parameters)​

尝试定义新的优先级参数时, 需要谨慎, 以免它们对不了解新定义优先级参数的现有端点或中介所执行的优先级处理产生不利干扰. 由于未知优先级参数会被忽略, 新的优先级参数不应以非向后兼容或非回退安全的方式改变对 urgency (见 Section 4.1) 或 incremental (见 Section 4.2) 优先级参数的解释, 或修改这些参数.

例如, 如果需要提供比八个 urgency 级别更细的粒度, 可以使用一个额外优先级参数来细分该范围. 不识别该参数的实现可以安全地继续使用粒度较粗的八个级别.

另一种方式是对 urgency 进行增强. 例如, 图形化 user agent 可以发送 visible 优先级参数, 指示所请求资源是否位于 viewport 内.

通用优先级参数优先于供应商特定, 应用特定或部署特定的值. 如果社区无法就通用值达成一致, 参数名称应相应地更具体 (例如, 使用标识供应商, 应用或部署的前缀).

4.3.1. 注册 (Registration)​

新的优先级参数可以通过在 "HTTP Priority" registry 中注册来定义. 该 registry 管理 Dictionary 中使用的 key (短文本字符串, 见 [STRUCTURED-FIELDS] 的 Section 3.2). 由于每个 HTTP 请求都可以有关联的优先级信号, 较短的 key 长度具有价值, 特别是单字符字符串. 为鼓励扩展并避免有吸引力的 key 值之间发生意外冲突, "HTTP Priority" registry 根据 key 长度采用两种注册策略.

  • key 长度为一的优先级参数注册请求使用 Specification Required 策略, 按 [RFC8126] 的 Section 4.6 执行.

  • key 长度大于一的优先级参数注册请求使用 Expert Review 策略, 按 [RFC8126] 的 Section 4.5 执行. 欢迎提供规范文档, 但不是必需的.

审查注册请求时, 指定专家可以考虑 Section 4.3 中提供的额外指导, 但不能将其作为拒绝的依据.

注册请求应使用以下模板:

Name: [与参数 key 匹配的优先级参数名称]

Description: [优先级参数语义和值的描述]

Reference: [定义该优先级参数的规范]

有关注册请求发送位置的详细信息, 请参见 ````https://www.iana.org/assignments/http-priority\```` 处的 registry.

最后于 更新