RFC 8941 - Structured Field Values for HTTP (HTTP结构化字段值)
发布日期: 2021年2月
状态: 标准跟踪协议 (Standards Track)
作者: M. Nottingham (Fastly), P-H. Kamp (The Varnish Cache Project)
摘要 (Abstract)
本文档描述了一组数据类型和相关算法,旨在使HTTP头部 (header) 和尾部 (trailer) 字段的定义和处理更加简单和安全,这些字段被称为"结构化字段 (Structured Fields)"、"结构化头部 (Structured Headers)"或"结构化尾部 (Structured Trailers)"。它适用于希望使用比传统HTTP字段值更严格的通用语法的新HTTP字段规范。
本备忘录状态 (Status of This Memo)
这是一份互联网标准跟踪文档。
本文档是互联网工程任务组 (IETF) 的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已获得互联网工程指导组 (IESG) 批准发布。有关互联网标准的更多信息,请参见RFC 7841第2节。
有关本文档当前状态、任何勘误以及如何提供反馈的信息,可访问 https://www.rfc-editor.org/info/rfc8941。
目录 (Table of Contents)
- 1. Introduction (简介)
- 1.1 Intentionally Strict Processing (有意的严格处理)
- 1.2 Notational Conventions (符号约定)
- 2. Defining New Structured Fields (定义新的结构化字段)
- 3. Structured Data Types (结构化数据类型)
- 3.1 Lists (列表)
- 3.2 Dictionaries (字典)
- 3.3 Items (项目)
- 4. Working with Structured Fields in HTTP (在HTTP中使用结构化字段)
- 4.1 Serializing Structured Fields (序列化)
- 4.2 Parsing Structured Fields (解析)
- 5. IANA Considerations (IANA考虑)
- 6. Security Considerations (安全考虑)
- 7. References (参考文献)
附录 (Appendices)
核心概念速览 (Quick Reference)
三种顶级数据类型
1. List (列表) - 有序的项目序列
2. Dictionary (字典) - 键值对的无序映射
3. Item (项目) - 单个值
六种基本数据类型
1. Integer (整数) - 范围: -999,999,999,999,999 到 999,999,999,999,999
2. Decimal (小数) - 最多3位小数
3. String (字符串) - 双引号包裹的文本
4. Token (令牌) - 不带引号的标识符
5. Byte Sequence (字节序列) - Base64编码的二进制数据
6. Boolean (布尔值) - ?1 (true) 或 ?0 (false)
示例
List (列表)
Example-List: "foo", "bar", baz
Example-List: 1, 2, (a b c)
Dictionary (字典)
Example-Dict: a=1, b=2
Example-Dict: key="value", flag
Item (项目)
Example-Integer: 42
Example-String: "hello world"
Example-Token: application/json
Example-Boolean: ?1
重要性
RFC 8941 是现代HTTP基础设施的核心规范,被广泛应用于:
1. HTTP/2 和 HTTP/3 头部
- 许多新的HTTP头部使用结构化字段格式
- 更高效的二进制编码
2. Client Hints (RFC 8942)
Sec-CH-UA: "Chromium";v="93", " Not;A Brand";v="99"
Sec-CH-Viewport-Width: 1024
Sec-CH-DPR: 2
3. CDN 和缓存控制
CDN-Cache-Control: max-age=3600, s-maxage=7200
4. 现代Web功能
- Cross-Origin Resource Policy (CORP)
- Cross-Origin Embedder Policy (COEP)
- 许多安全相关头部
为什么需要结构化字段?
传统HTTP头部的问题
# 不同的字段使用不同的语法:
Cache-Control: max-age=3600, private
Accept: text/html, application/json;q=0.9
Link: `https://example.com`; rel="preload"
# 每个字段都需要自定义解析器
# 容易出错、难以维护
结构化字段的优势
# 统一的语法和解析规则
Structured-Header: a=1, b=2, c=(x y z)
# 优点:
✓ 标准化的数据类型
✓ 明确的解析算法
✓ 更好的互操作性
✓ 支持未来优化 (如HTTP/3的二进制编码)
设计原则
1. 有意的严格性
- 解析失败立即报错,不尝试"修复"
- 避免歧义和安全问题
- 促进互操作性
2. 向前兼容
- 抽象数据模型与序列化分离
- 未来可以定义更高效的序列化方式
3. 实用性优先
- 基于现有HTTP字段的实践经验
- 平衡表达能力和复杂度
快速示例
定义一个新的结构化头部
假设我们要定义一个 "Example-Priorities" 头部:
规范定义:
-----------
Example-Priorities 头部是一个结构化字段 (Structured Field)。
其值必须是一个字典 (Dictionary)。
字典的键是资源标识符 (token),值是优先级 (integer)。
示例:
-----
Example-Priorities: css=10, js=5, images=1
解析和使用
// 伪代码示例
const header = "css=10, js=5, images=1";
const dict = parseDictionary(header);
console.log(dict.get('css')); // 10
console.log(dict.get('js')); // 5
console.log(dict.get('images')); // 1
相关资源 (Related Resources)
- 官方原文: RFC 8941 (TXT)
- 官方页面: RFC 8941 DataTracker
- 勘误表: RFC Editor Errata
- 相关RFC:
- RFC 7230 - HTTP/1.1消息语法
- RFC 8942 - Client Hints (使用结构化字段)
适用对象
- HTTP规范作者: 定义新的HTTP头部时使用
- 浏览器实现者: 实现解析和序列化算法
- CDN和代理开发者: 处理现代HTTP头部
- Web开发者: 理解现代HTTP头部格式