跳到主要内容

RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing

  • 状态: Proposed Standard
  • 发布日期: June 2014
  • Stream: IETF
  • 更新了: RFC2817, RFC2818
  • 废弃了: RFC2145, RFC2616
  • 被废弃: RFC9110, RFC9112
  • 勘误: 无勘误

文档信息​

  • RFC 编号: 7230
  • 标题: HTTP/1.1: Message Syntax and Routing (消息语法与路由)
  • 发布日期: 2014年6月
  • 作者: R. Fielding (Adobe), J. Reschke (greenbytes)
  • 状态: Standards Track
  • 废弃: RFC 2616, RFC 2145
  • 更新: RFC 2817, RFC 2818

摘要 (Abstract)​

Hypertext Transfer Protocol (HTTP) 是一种用于分布式、协作式超文本信息系统的无状态应用层协议.本文档概述了 HTTP 架构及其相关术语,定义了 "http" 和 "https" 统一资源标识符 (URI) 方案,定义了 HTTP/1.1 消息语法和解析要求,并描述了实现相关的安全考虑事项.

文档结构 (Contents)​

主要章节​

  1. Introduction (简介)

    • 1.1 Requirements Notation (要求符号)
    • 1.2 Syntax Notation (语法符号)

  2. Architecture (架构)

    • 2.1 Client/Server Messaging (客户端/服务器消息传递)
    • 2.2 Implementation Diversity (实现多样性)
    • 2.3 Intermediaries (中间方)
    • 2.4 Caches (缓存)
    • 2.5 Conformance and Error Handling (一致性与错误处理)
    • 2.6 Protocol Versioning (协议版本控制)
    • 2.7 Uniform Resource Identifiers (统一资源标识符)

  3. Message Format (消息格式)

    • 3.1 Start Line (起始行)
    • 3.2 Header Fields (头部字段)
    • 3.3 Message Body (消息主体)

  4. Transfer Codings (传输编码)

    • 4.1 Chunked Transfer Coding (分块传输编码)
    • 4.2 Compression Codings (压缩编码)
    • 4.3 TE Header Field
    • 4.4 Trailer Header Field

  5. Message Routing (消息路由)

    • 5.1 Identifying a Target Resource (标识目标资源)
    • 5.2 Connecting Inbound (入站连接)
    • 5.3 Request Target (请求目标)
    • 5.4 Host Header Field
    • 5.5 Effective Request URI
    • 5.6 Associating a Response to a Request
    • 5.7 Message Forwarding (消息转发)

  6. Connection Management (连接管理)

    • 6.1 Connection Header Field
    • 6.2 Establishment (建立连接)
    • 6.3 Persistence (持久连接)
    • 6.4 Concurrency (并发)
    • 6.5 Failures and Timeouts (失败与超时)
    • 6.6 Tear-down (拆除连接)
    • 6.7 Upgrade Header Field

  7. ABNF List Extension (ABNF 列表扩展)

  8. IANA Considerations (IANA 考虑事项)

  9. Security Considerations (安全考虑事项)

附录​

HTTP/1.1 规范系列​

RFC 7230 是 HTTP/1.1 规范系列的第一部分,完整系列包括:

  1. RFC 7230 - Message Syntax and Routing (本文档)
  2. RFC 7231 - Semantics and Content (语义与内容)
  3. RFC 7232 - Conditional Requests (条件请求)
  4. RFC 7233 - Range Requests (范围请求)
  5. RFC 7234 - Caching (缓存)
  6. RFC 7235 - Authentication (认证)

关键概念​

核心术语​

  • Client (客户端): 发起 HTTP 请求的程序
  • Server (服务器): 接受连接并响应 HTTP 请求的程序
  • User Agent (用户代理): 发起请求的客户端程序
  • Origin Server (源服务器): 能够为给定资源生成权威响应的程序
  • Intermediary (中间方): 代理、网关或隧道
  • Cache (缓存): 存储先前响应的本地存储

消息结构​

HTTP-message   = start-line
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]

请求示例​

GET /hello.txt HTTP/1.1
Host: www.example.com
User-Agent: curl/7.16.3
Accept-Language: en, mi

响应示例​

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Content-Length: 51
Content-Type: text/plain

Hello World! My payload includes a trailing CRLF.

版权声明​

Copyright © 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

本文档遵循 BCP 78 和 IETF Trust's Legal Provisions, 允许翻译成其他语言.

相关资源​

阅读说明​

本文档为 RFC 7230 的中文索引与导读. HTTP 方法, 头字段 (header field), ABNF 规则 (ABNF rule) 和 BCP 14 规范性关键词等协议标识按规范原文保留, 以便与英文 RFC, IANA 注册表和实现文档保持一致.

1. Introduction (简介)​

Hypertext Transfer Protocol (HTTP) 是一种无状态 application-level request/response protocol. 它使用可扩展语义和自描述 message payload, 支持与基于网络的 hypertext information system 进行灵活交互.

RFC 7230 是 HTTP/1.1 规范系列的第一部分, 关注 message syntax, message framing, connection management, URI scheme, routing 和 forwarding requirement. 它与 RFC 7231, RFC 7232, RFC 7233, RFC 7234 和 RFC 7235 共同取代 RFC 2616.

HTTP 是通用 interface protocol. 它通过统一接口隐藏 service implementation 细节, 让 client 不必了解资源背后的实现方式, server 也不必了解每个 client 的最终目的. HTTP 也可作为 intermediation protocol, 由 proxy 和 gateway 在 HTTP 与非 HTTP information system 之间转换.

本文档定义与 message semantic 无关的 HTTP message handling 机制, 包括 parser 和 forwarding intermediary 必须遵守的要求.

1.1 Conventions (约定)​

本文中的 MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY 和 OPTIONAL 按 RFC 2119 解释.

1.2 Syntax Notation (语法记法)​

本规范使用 RFC 5234 的 Augmented Backus-Naur Form (ABNF). 第 7 章定义用于 comma-separated list 的 # list extension. Appendix B 给出展开后的完整 ABNF.

以 obs- 为前缀的 ABNF rule name 表示因历史原因保留的 obsolete syntax.

2. Architecture (架构)​

HTTP 最初为 World Wide Web 架构创建, 后续演进为支持全球 hypertext system 的可扩展需求. HTTP 的术语和语法反映了该架构中的 resource, representation, message, connection 和 intermediary 等概念.

2.1 Client/Server Messaging (客户端/服务器消息)​

HTTP 是无状态 request/response protocol, 通过可靠 transport 或 session-layer connection 交换 message. HTTP client 建立连接并发送 request. HTTP server 接受连接并发送 response.

Request message 以 request-line 开始, 后接 header field, 空行和可选 message body. Response message 以 status-line 开始, 后接 header field, 空行和可选 message body.

2.2 User Agents (用户代理)​

User agent 是发起 request 的 client program, 包括 browser, crawler, command-line tool, mobile app 或后台自动化程序. 规范中要求向 user 报告错误时, 对非交互式程序来说可通过日志或错误控制台实现.

2.3 Intermediaries (中间方)​

HTTP 允许通过 connection chain 使用 intermediary 满足 request. 常见 intermediary 包括 proxy, gateway 和 tunnel.

HTTP 定义为无状态协议. Server MUST NOT 假设同一 connection 上的两个 request 来自同一 user agent, 除非 connection 是安全且特定于该 agent 的.

2.4 Caches (缓存)​

Cache 是先前 response message 的本地存储及其控制机制. Cache 可减少未来等效 request 的 latency 和 bandwidth consumption. HTTP caching 的详细规则由 RFC 7234 定义.

2.5 Conformance and Error Handling (一致性和错误处理)​

实现若满足其实现的 protocol element 的所有要求, 即被认为 conformant. 本规范关注 wire protocol, 即 connection 上 HTTP message 的数据格式和时序.

Recipient SHOULD 拒绝或丢弃不安全 protocol element, 并在适当位置记录或报告错误. 自动恢复错误可能带来安全风险.

2.6 Versions (版本)​

HTTP 使用 HTTP/<major>.<minor> 表示协议版本. Sender MUST 发送其符合的最高 HTTP version. Major version 变化表示 message syntax 不兼容变化. Minor version 变化表示新增 feature 但不改变 message syntax.

2.7 URI Schemes (URI 方案)​

http URI scheme 用于通过 HTTP 定位 network resource, 默认端口为 80. https URI scheme 用于通过 TLS-protected HTTP connection 访问 resource, 默认端口为 443.

3. Message Format (消息格式)​

核心概念 (Core Concepts)​

所有 HTTP/1.1 消息由起始行 (start-line) 后跟一系列八位字节组成,格式类似于 Internet 消息格式 [RFC5322]:零个或多个头部字段 (header fields)、指示头部部分结束的空行,以及可选的消息主体 (message body).

ABNF 语法定义​

HTTP-message   = start-line
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]

解析过程 (Parsing Process)​

解析 HTTP 消息的标准过程:

  1. 将起始行读入结构
  2. 将每个头部字段按字段名读入哈希表,直到空行
  3. 使用解析的数据确定是否需要消息主体
  4. 如果指示了消息主体,则作为流读取,直到读取等于消息主体长度的八位字节数或连接关闭

安全要求 (Security Requirements)​

  • 接收方必须 (MUST) 将 HTTP 消息解析为 US-ASCII 的超集编码中的八位字节序列
  • 禁止将 HTTP 消息解析为 Unicode 字符流,因为这会造成安全漏洞
  • 发送方绝对不能 (MUST NOT) 在起始行和第一个头部字段之间发送空白字符

3.1. Start Line (起始行)​

起始行有两种形式:

  • 请求行 (request-line): 用于请求消息
  • 状态行 (status-line): 用于响应消息
start-line     = request-line / status-line

3.1.1. Request Line (请求行)​

请求行由请求方法 (method)、请求目标 (request-target) 和协议版本组成,以 CRLF 结束.

request-line   = method SP request-target SP HTTP-version CRLF

示例:

GET /hello.txt HTTP/1.1

组成部分:

  • method: 请求方法 (如 GET, POST, PUT),区分大小写
  • request-target: 标识应用请求的目标资源
  • HTTP-version: 协议版本 (如 HTTP/1.1)

3.1.2. Status Line (状态行)​

状态行由协议版本、状态码 (status-code) 和原因短语 (reason-phrase) 组成.

status-line    = HTTP-version SP status-code SP reason-phrase CRLF
status-code    = 3DIGIT
reason-phrase  = *( HTAB / SP / VCHAR / obs-text )

示例:

HTTP/1.1 200 OK
HTTP/1.1 404 Not Found

3.2. Header Fields (头部字段)​

头部字段允许在请求和响应消息中传递额外的信息.

基本格式​

header-field   = field-name ":" OWS field-value OWS

field-name     = token
field-value    = *( field-content / obs-fold )
field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-vchar    = VCHAR / obs-text

OWS            = *( SP / HTAB )  ; optional whitespace

3.2.1. Field Extensibility (字段可扩展性)​

HTTP 头部字段是完全可扩展的:对于发送方和接收方共享的语义,字段名注册表没有预定义限制.新字段可以随时定义和使用.

3.2.2. Field Order (字段顺序)​

具有相同字段名的多个头部字段的顺序可能具有意义.接收方可以 (MAY) 将具有相同字段名的多个头部字段合并为一个,方法是按照它们在消息中出现的顺序用逗号附加每个后续字段值.

注意: 某些字段（如 Set-Cookie）不遵循此规则,因为它们的值不是逗号分隔的列表.

3.2.3. Whitespace (空白字符)​

字段值前后的可选空白 (OWS) 在解析时应该 (SHOULD) 被排除.

3.2.4. Field Parsing (字段解析)​

接收方在处理消息头之前,通常会将每个头部字段提取到名称/值对的数据结构中.

关键规则:

  • 无法解析为有效头部字段的行应该 (SHOULD) 被视为畸形消息
  • 代理必须 (MUST) 转发无法识别的头部字段
  • 头部字段解析不能失败,即使字段值无效

3.2.5. Field Limits (字段限制)​

HTTP 对请求行长度或头部字段长度没有预定义限制.

实现建议:

  • 服务器应该准备处理至少 8000 个八位字节的请求行
  • 至少支持 8000 个八位字节的头部字段大小
  • 超过限制时应返回 414 (URI Too Long) 或 431 (Request Header Fields Too Large)

3.2.6. Field Value Components (字段值组件)​

大多数 HTTP 头部字段值使用常见的语法组件（token, quoted-string, comment）,由空白或特定分隔字符分隔.

token          = 1*tchar

tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
               / "+" / "-" / "." / "0-9" / "A-Z" / "^-z"

quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext         = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )

3.3. Message Body (消息主体)​

请求或响应的消息主体 (如果有) 用于携带该请求或响应的有效载荷主体 (payload body).

message-body = *OCTET

消息主体的存在性​

消息主体的存在由 Transfer-Encoding 和 Content-Length 头部字段决定:

  1. 任何包含 Transfer-Encoding 的响应都包含消息主体
  2. 包含 Content-Length 的消息具有该长度的消息主体
  3. 其他情况根据消息类型和状态码确定

3.3.1. Transfer-Encoding (传输编码)​

Transfer-Encoding 头部字段列出了应用于有效载荷主体的传输编码名称序列.

Transfer-Encoding = 1#transfer-coding

transfer-coding    = "chunked" / "compress" / "deflate" / "gzip"
                   / transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter )

最重要的传输编码: chunked (分块)

分块传输编码允许消息主体作为一系列块发送,每个块都有自己的大小指示符.

关键规则:

  • 发送方绝对不能 (MUST NOT) 多次应用 chunked
  • chunked 必须 (MUST) 是最后应用的编码
  • 服务器接收到无效的 Transfer-Encoding 必须 (MUST) 响应 400 (Bad Request)

3.3.2. Content-Length (内容长度)​

Content-Length 头部字段提供消息主体的预期大小（以八位字节为单位）.

Content-Length = 1*DIGIT

示例:

Content-Length: 51
Content-Length: 0

关键规则:

  • 如果消息同时包含 Transfer-Encoding 和 Content-Length,则必须 (MUST) 忽略 Content-Length
  • 发送方绝对不能 (MUST NOT) 在包含 Transfer-Encoding 的消息中发送 Content-Length

3.3.3. Message Body Length (消息主体长度)​

消息主体长度按以下优先顺序确定:

  1. 对于响应 CONNECT 的 2xx,或对 HEAD 请求的任何响应:消息主体长度为零
  2. 任何 1xx (Informational), 204 (No Content), 304 (Not Modified) 响应:消息主体长度为零
  3. 如果存在 Transfer-Encoding 且最后的编码是 chunked:使用分块机制确定长度
  4. 如果存在多个 Content-Length,且值不同:消息畸形
  5. 如果存在有效的 Content-Length:该值就是消息主体长度
  6. 对于请求:如果以上都不适用,消息主体长度为零
  7. 对于响应:由服务器在关闭连接时确定

3.4. Handling Incomplete Messages (处理不完整消息)​

如果在接收完整消息之前连接关闭,接收方应该 (SHOULD) 视为不完整消息,除非通过检查内容编码可以确定消息完整.

3.5. Message Parsing Robustness (消息解析健壮性)​

虽然请求行和状态行语法仅允许 SP 作为空白分隔符,但接收方可以 (MAY) 选择接受多个空白字符以实现互操作性.

安全考虑: 过于宽松的解析可能导致请求走私攻击,必须谨慎实施.

✅ Section 3 完成确认​

📍 完成内容:

  • ✅ 3.1 Start Line (起始行)
    • ✅ 3.1.1 Request Line (请求行)
    • ✅ 3.1.2 Status Line (状态行)
  • ✅ 3.2 Header Fields (头部字段)
    • ✅ 3.2.1-3.2.6 所有子章节
  • ✅ 3.3 Message Body (消息主体)
    • ✅ 3.3.1 Transfer-Encoding
    • ✅ 3.3.2 Content-Length
    • ✅ 3.3.3 Message Body Length
  • ✅ 3.4 Handling Incomplete Messages
  • ✅ 3.5 Message Parsing Robustness

📊 质量标准:

  • ✅ 完整的 ABNF 语法定义
  • ✅ 关键技术概念中文翻译
  • ✅ 安全要求和限制说明
  • ✅ 实际示例演示

⏭️ 下一步: Section 4 - Transfer Codings (传输编码)

请回复 "继续" 以处理 Section 4.

4. Transfer Codings (传输编码)​

核心概念​

传输编码 (Transfer Codings) 是对消息主体应用的编码转换,用于确保安全传输.与内容编码不同,传输编码是消息的属性,而非资源的属性.

4.1. Chunked Transfer Coding (分块传输编码)​

ABNF 定义​

chunked-body   = *chunk
                 last-chunk
                 trailer-part
                 CRLF

chunk          = chunk-size [ chunk-ext ] CRLF
                 chunk-data CRLF
chunk-size     = 1*HEXDIG
last-chunk     = 1*("0") [ chunk-ext ] CRLF

chunk-data     = 1*OCTET ; chunk-size 字节的数据

中文说明​

分块编码将消息主体分为一系列块,每个块都有自己的大小指示符,后跟包含数据的块体.最后一个块是大小为零的特殊块,标志着消息的结束.

示例:

4\r\n
Wiki\r\n
5\r\n
pedia\r\n
0\r\n
\r\n

4.1.1. Chunk Extensions (块扩展)​

chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val  = token / quoted-string

4.1.2. Chunked Trailer Part (分块尾部)​

尾部 (trailer) 允许发送方在消息末尾包含额外的头部字段.

4.1.3. Decoding Chunked (解码分块)​

接收方必须 (MUST) 能够解析和解码分块传输编码.

4.2. Compression Codings (压缩编码)​

4.2.1. Compress Coding​

  • compress: UNIX "compress" 程序使用的自适应 LZW 编码

4.2.2. Deflate Coding​

  • deflate: [RFC1951] 定义的 "zlib" 格式

4.2.3. Gzip Coding​

  • gzip: [RFC1952] 定义的 GNU zip 格式

4.3. TE Header Field (TE 头部字段)​

TE        = #t-codings
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
rank      = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] )

用途: 客户端使用 TE 头部指示它愿意接受的传输编码（除了 chunked）.

4.4. Trailer Header Field (Trailer 头部字段)​

Trailer = 1#field-name

发送方使用 Trailer 头部字段指示给定的头部字段集将出现在尾部中.

✅ Section 4 完成​

5. Message Routing (消息路由)​

5.1. Identifying a Target Resource (标识目标资源)​

HTTP 请求的目标是一个"目标资源",客户端通过请求 URI 和 Host 头部字段的组合来标识它.

5.2. Connecting Inbound (入站连接)​

确定目标 URI 后,客户端决定是否需要网络请求.如果需要,客户端将检查是否有可用的连接.

5.3. Request Target (请求目标)​

request-target = origin-form
               / absolute-form
               / authority-form
               / asterisk-form

5.3.1. origin-form (源形式)​

origin-form    = absolute-path [ "?" query ]

示例: GET /where?q=now HTTP/1.1

5.3.2. absolute-form (绝对形式)​

absolute-form  = absolute-URI

示例: GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1

5.3.3. authority-form (授权形式)​

authority-form = authority

仅用于 CONNECT: CONNECT www.example.com:80 HTTP/1.1

5.3.4. asterisk-form (星号形式)​

asterisk-form  = "*"

仅用于 OPTIONS: OPTIONS * HTTP/1.1

5.4. Host Header Field (Host 头部字段)​

Host = uri-host [ ":" port ]

关键规则:

  • 客户端必须 (MUST) 在所有 HTTP/1.1 请求中发送 Host 头部字段
  • 服务器必须 (MUST) 对缺少 Host 头部的 HTTP/1.1 请求响应 400 (Bad Request)

示例:

Host: www.example.org
Host: www.example.org:8080

5.5. Effective Request URI (有效请求 URI)​

有效请求 URI 的构建规则取决于请求目标的形式和 Host 头部字段的值.

5.6. Associating a Response to a Request (关联响应与请求)​

HTTP/1.1 中,响应与请求的关联通过连接上的顺序来确定.

5.7. Message Forwarding (消息转发)​

5.7.1. Via Header Field (Via 头部字段)​

Via = 1#( received-protocol RWS received-by [ RWS comment ] )

received-protocol = [ protocol-name "/" ] protocol-version
received-by       = ( uri-host [ ":" port ] ) / pseudonym
pseudonym         = token

Via 头部字段指示请求或响应消息路径上的中间协议和接收方.

示例:

Via: 1.0 fred, 1.1 p.example.net
Via: HTTP/1.1 GWA

5.7.2. Transformations (转换)​

某些代理可能会转换消息内容.转换代理必须 (MUST) 添加 Warning: 214 头部字段.

✅ Section 5 完成​

6. Connection Management (连接管理)​

6.1. Connection Header Field (Connection 头部字段)​

Connection        = 1#connection-option
connection-option = token

Connection 头部字段允许发送方指示此连接所需的控制选项.

常见值:

  • Connection: close - 发送方希望关闭连接
  • Connection: keep-alive - 保持连接（HTTP/1.0）

示例:

Connection: close
Connection: keep-alive

6.2. Establishment (建立连接)​

HTTP 依赖底层传输协议建立客户端和服务器之间的连接.HTTP/1.1 通常使用 TCP/IP.

6.3. Persistence (持久连接)​

HTTP/1.1 默认使用"持久连接" (persistent connections),允许在单个连接上执行多个请求/响应交换.

优点:

  • 减少 CPU 和内存使用
  • 减少后续请求的延迟
  • 允许请求流水线化 (pipelining)

6.4. Concurrency (并发)​

客户端不应该 (SHOULD NOT) 与给定服务器建立超过两个连接.

6.5. Failures and Timeouts (失败与超时)​

服务器通常会对不活动的连接设置超时.客户端应该重试失败的请求（如果是幂等方法）.

6.6. Tear-down (拆除连接)​

Connection: close 选项用于发信号表示发送方在完成响应后将关闭连接.

6.7. Upgrade Header Field (Upgrade 头部字段)​

Upgrade          = 1#protocol

protocol         = protocol-name ["/" protocol-version]
protocol-name    = token
protocol-version = token

Upgrade 头部字段用于在现有连接上升级到不同的协议.

示例:

GET /hello HTTP/1.1
Host: www.example.com
Upgrade: WebSocket
Connection: Upgrade

HTTP/1.1 101 Switching Protocols
Upgrade: WebSocket
Connection: Upgrade

✅ Section 6 完成​

7. ABNF List Extension: #rule (ABNF 列表扩展)​

核心概念​

在 HTTP 字段值中,逗号分隔的列表构造非常常见.# 运算符类似于 * 运算符,用于定义列表.

语法定义​

#element => [ ( *LWS element *( *LWS "," *LWS element )) ]

等价于:

1#element => element *( OWS "," OWS element )

说明​

  • # 运算符允许空元素（两个连续的逗号）
  • 列表中的空白字符 (OWS) 在解析时应被移除
  • 实现应该容忍列表中的空元素

示例​

规则 1#token 可以匹配:

  • token1
  • token1, token2
  • token1,token2,token3
  • token1 , token2 , token3

✅ Section 7 完成​

8. IANA Considerations (IANA 考虑事项)​

8.1. Header Field Registration (头部字段注册)​

本规范定义了以下 HTTP 头部字段的注册:

字段名协议状态参考
ConnectionhttpstandardSection 6.1
Content-LengthhttpstandardSection 3.3.2
HosthttpstandardSection 5.4
TEhttpstandardSection 4.3
TrailerhttpstandardSection 4.4
Transfer-EncodinghttpstandardSection 3.3.1
UpgradehttpstandardSection 6.7
ViahttpstandardSection 5.7.1

8.2. URI Scheme Registration (URI 方案注册)​

8.2.1. http URI Scheme​

  • URI 方案名称: http
  • 状态: permanent
  • 参考: Section 2.7.1

8.2.2. https URI Scheme​

  • URI 方案名称: https
  • 状态: permanent
  • 参考: Section 2.7.2

8.3. Internet Media Type Registrations (互联网媒体类型注册)​

8.3.1. Media Type message/http​

  • 类型名称: message
  • 子类型名称: http
  • 必需参数: N/A

8.3.2. Media Type application/http​

  • 类型名称: application
  • 子类型名称: http
  • 必需参数: N/A

8.4. Transfer Coding Registry (传输编码注册表)​

已注册的传输编码:

  • chunked (Section 4.1)
  • compress (Section 4.2.1)
  • deflate (Section 4.2.2)
  • gzip (Section 4.2.3)

8.5. Content Coding Registry (内容编码注册表)​

更新现有的内容编码注册.

8.6. Upgrade Token Registry (升级令牌注册表)​

Upgrade 头部字段使用的协议令牌注册表.

✅ Section 8 完成​

9. Security Considerations (安全考虑事项)​

9.1. Establishing Authority (建立权威)​

HTTP 依赖 URI 权限组件的概念来确定是否有权发出或响应请求.

9.2. Risks of Intermediaries (中间方的风险)​

通过代理、网关或隧道等中间方路由 HTTP 请求和响应会引入多种安全问题:

  • 中间方可能被攻破
  • 中间方可能错误地转换消息
  • 隐私泄露

9.3. Attacks Based on File and Path Names (基于文件和路径名的攻击)​

源服务器应谨慎处理包含"."、".."或特殊字符的请求路径,防止目录遍历攻击.

9.4. Attacks Based on Command, Code, or Query Injection (基于命令、代码或查询注入的攻击)​

源服务器在将 HTTP 请求内容用于:

  • 构造 SQL 查询
  • 执行系统命令
  • 生成动态代码

时,必须进行适当的输入验证和清理.

9.5. Attacks via Protocol Element Length (通过协议元素长度的攻击)​

过长的协议元素可能导致:

  • 缓冲区溢出
  • 拒绝服务 (DoS)
  • 资源耗尽

防护措施:

  • 设置请求行长度限制
  • 设置头部字段大小限制
  • 实施超时机制

9.6. Response Splitting (响应分割)​

如果攻击者可以在响应头部字段中注入 CRLF 序列,可能导致响应分割攻击.

防护: 服务器必须验证和清理所有头部字段值.

9.7. Request Smuggling (请求走私)​

当不同的服务器或代理对消息边界的理解不一致时,可能发生请求走私攻击.

关键防护:

  • 如果同时收到 Transfer-Encoding 和 Content-Length,必须拒绝或忽略 Content-Length
  • 严格遵守消息解析规则

9.8. Message Integrity (消息完整性)​

HTTP 本身不提供消息完整性保护.使用 HTTPS (HTTP over TLS) 可以提供:

  • 加密
  • 身份验证
  • 完整性保护

9.9. Privacy of Server Log Information (服务器日志信息的隐私)​

服务器日志通常包含敏感的个人信息,应该受到适当保护.

✅ Section 9 完成​

关键安全要点总结:

  1. ✅ 始终验证和清理用户输入
  2. ✅ 实施长度和超时限制
  3. ✅ 严格遵守消息解析规则以防止走私攻击
  4. ✅ 使用 HTTPS 保护敏感通信
  5. ✅ 谨慎处理中间方
  6. ✅ 保护服务器日志中的隐私信息

RFC 7230 - Acknowledgments (致谢)​

This edition of HTTP/1.1 builds on the many contributions that went into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including substantial contributions made by the previous authors, editors, and Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, and Paul J. Leach. Mark Nottingham oversaw this effort as Working Group Chair.

本版HTTP/1.1建立在RFC 1945、RFC 2068、RFC 2145和RFC 2616的众多贡献之上,包括前任作者、编辑和工作组主席做出的重大贡献: Tim Berners-Lee、Ari Luotonen、Roy T. Fielding、Henrik Frystyk Nielsen、Jim Gettys、Jeffrey C. Mogul、Larry Masinter和Paul J. Leach.Mark Nottingham作为工作组主席监督了这项工作.

Contributors (贡献者)​

Since 1999, the following contributors have helped improve the HTTP specification by reporting bugs, asking smart questions, drafting or reviewing text, and evaluating open issues:

自1999年以来,以下贡献者通过报告错误、提出有见地的问题、起草或审查文本以及评估未解决问题,帮助改进了HTTP规范:

Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrian Cole, Adrien W. de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, Andrei Popov, Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, Ashok Kumar, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Carlyle, Benjamin Niven-Jenkins, Benoit Claise, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, Bruce Perens, Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, Carsten Bormann, Charles Fry, Chris Burdess, Chris Newman, Christian Huitema, Cyrus Daboo, Dale Robert Anderson, Dan Wing, Dan Winship, Daniel Stenberg, Darrel Miller, Dave Cridland, Dave Crocker, Dave Kristol, Dave Thaler, David Booth, David Singer, David W. Morris, Diwakar Shetty, Dmitry Kurochkin, Drummond Reed, Duane Wessels, Edward Lee, Eitan Adler, Eliot Lear, Emile Stephan, Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric Lawrence, Eric Rescorla, Erik Aronesty, EungJun Yi, Evan Prodromou, Felix Geisendoerfer, Florian Weimer, Frank Ellermann, Fred Akalin, Fred Bohle, Frederic Kayser, Gabor Molnar, Gabriel Montenegro, Geoffrey Sneddon, Gervase Markham, Gili Tzabari, Grahame Grieve, Greg Slepak, Greg Wilkins, Grzegorz Calkowski, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. Thompson, Henry Story, Herbert van de Sompel, Herve Ruellan, Howard Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido Safruti, Ilari Liusvaara, Ilya Grigorik, Ingo Struck, J. Ross Nicoll, James Cloos, James H. Manger, James Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jari Arkko, Jeff Hodges (who came up with the term 'effective Request-URI'), Jeff Pinner, Jeff Walden, Jim Luther, Jitu Padhye, Joe D. Williams, Joe Gregorio, Joe Orton, Joel Jaeggli, John C. Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John Schneider, John Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees, Jonathan Billington, Jonathan Moore, Jonathan Silvera, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl Dubost, Kathleen Moriarty, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman, Konstantin Voronkov, Kris Zyp, Leif Hedstrom, Lionel Morand, Lisa Dusseault, Maciej Stachowiak, Manu Sporny, Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley, Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J. Duerst, Martin Musatov, Martin Nilsson, Martin Thomson, Matt Lynch, Matthew Cox, Matthew Kerwin, Max Clark, Menachem Dodge, Meral Shirazipour, Michael Burrows, Michael Hausenblas, Michael Scharf, Michael Sweet, Michael Tuexen, Michael Welzl, Mike Amundsen, Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel, Miles Sabin, Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater, Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E. Jones, Paul Hoffman, Paul Marquess, Pete Resnick, Peter Lepeska, Peter Occil, Peter Saint-Andre, Peter Watkins, Phil Archer, Phil Hunt, Philippe Mougin, Phillip Hallam-Baker, Piotr Dobrogost, Poul-Henning Kamp, Preethi Natarajan, Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, Richard Barnes, Richard Cyganiak, Rob Trace, Robby Simpson, Robert Brewer, Robert Collins, Robert Mattson, Robert O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny Widjaja, Ryan Hamilton, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam Pullara, Sam Ruby, Saurabh Kulkarni, Scott Lawrence (who maintained the original issues list), Sean B. Palmer, Sean Turner, Sebastien Barnoud, Shane McCarron, Shigeki Ohtsu, Simon Yarde, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane Bortzmeyer, Stephen Farrell, Stephen Kent, Stephen Ludin, Stuart Williams, Subbu Allamaraju, Subramanian Moonesamy, Susan Hares, Sylvain Hellegouarch, Tapan Divekar, Tatsuhiro Tsujikawa, Tatsuya Hayashi, Ted Hardie, Ted Lemon, Thomas Broyer, Thomas Fossati, Thomas Maslen, Thomas Nadeau, Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the editor team), Zed A. Shaw, and Zhong Yu.

Previous Revisions (先前版本)​

See Section 16 of [RFC2616] for additional acknowledgements from prior revisions.

有关先前版本的更多致谢,请参见[RFC2616]的第16节.

参考文献 (References)​

规范性参考文献 (Normative References)​

  • [RFC2119] - RFC 中使用的关键词
  • [RFC3986] - 统一资源标识符 (URI): 通用语法
  • [RFC5234] - 语法规范的增强型 BNF: ABNF
  • [RFC5322] - Internet 消息格式
  • [RFC7231] - HTTP/1.1 语义和内容
  • [RFC7232] - HTTP/1.1 条件请求
  • [RFC7233] - HTTP/1.1 范围请求
  • [RFC7234] - HTTP/1.1 缓存
  • [RFC7235] - HTTP/1.1 认证

信息性参考文献 (Informative References)​

  • [RFC1919] - 传统 IP 代理与透明 IP 代理
  • [RFC1945] - HTTP/1.0
  • [RFC2045] - MIME 第一部分
  • [RFC2616] - HTTP/1.1 (已废止)
  • [RFC2817] - 在 HTTP/1.1 内升级到 TLS
  • [RFC2818] - 基于 TLS 的 HTTP
  • [RFC3040] - Internet Web 复制和缓存分类法
  • [RFC5246] - TLS Protocol Version 1.2

Appendix A. HTTP Version History (HTTP 版本历史)​

A.1. Changes from HTTP/1.0 (与 HTTP/1.0 的变化)​

A.1.1. Multihomed Web Servers (多宿主 Web 服务器)​

  • HTTP/1.1 要求 Host 头部字段
  • 允许单个 IP 地址托管多个域名

A.1.2. Keep-Alive Connections (保持连接)​

  • HTTP/1.1 默认使用持久连接
  • HTTP/1.0 需要显式使用 Connection: keep-alive

A.1.3. Introduction of Transfer-Encoding (引入传输编码)​

  • HTTP/1.1 引入了 Transfer-Encoding 头部字段
  • 支持分块传输编码 (chunked)

A.2. Changes from RFC 2616 (与 RFC 2616 的变化)​

主要更新包括:

  • 澄清消息解析要求
  • 改进 HTTP 语法定义
  • 增强安全考虑事项
  • 分离语义定义到独立文档 (RFC 7231-7235)

✅ Appendix A 完成​