Skip to main content

1. Introduction (简介)

🇬🇧 English Version​

The Hypertext Transfer Protocol (HTTP) is a stateless application-level request/response protocol that uses extensible semantics and self-descriptive message payloads for flexible interaction with network-based hypertext information systems. This document is the first in a series of documents that collectively form the HTTP/1.1 specification:

  1. "Message Syntax and Routing" (this document)
  2. "Semantics and Content" [RFC7231]
  3. "Conditional Requests" [RFC7232]
  4. "Range Requests" [RFC7233]
  5. "Caching" [RFC7234]
  6. "Authentication" [RFC7235]

This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP versioning). This specification also updates the use of CONNECT to establish a tunnel, previously defined in RFC 2817, and defines the "https" URI scheme that was described informally in RFC 2818.

HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used effectively in many different contexts and for which implementations can evolve independently over time.

HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information systems. HTTP proxies and gateways can provide access to alternative information services by translating their diverse protocols into a hypertext format that can be viewed and manipulated by clients in the same way as HTTP services.

One consequence of this flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead, we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.

This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries.

🇨🇳 中文版本​

Hypertext Transfer Protocol (HTTP, 超文本传输协议) 是一种无状态 (stateless) 的应用层 (application-level) 请求/响应协议 (request/response protocol), 它使用可扩展的语义 (extensible semantics) 和自描述的消息负载 (self-descriptive message payloads), 以实现与基于网络的超文本信息系统的灵活交互。本文档是构成 HTTP/1.1 规范的系列文档中的第一部分:

  1. "Message Syntax and Routing (消息语法与路由)" (本文档)
  2. "Semantics and Content (语义与内容)" [RFC7231]
  3. "Conditional Requests (条件请求)" [RFC7232]
  4. "Range Requests (范围请求)" [RFC7233]
  5. "Caching (缓存)" [RFC7234]
  6. "Authentication (认证)" [RFC7235]

本 HTTP/1.1 规范废弃了 RFC 2616 和 RFC 2145 (关于 HTTP 版本控制)。本规范还更新了 CONNECT 方法用于建立隧道的使用方式 (先前在 RFC 2817 中定义), 并定义了在 RFC 2818 中非正式描述的 "https" URI 方案 (URI scheme)。

HTTP 是一种用于信息系统的通用接口协议 (generic interface protocol)。它的设计目的是通过向客户端呈现统一的接口来隐藏服务实现的细节, 该接口独立于所提供资源的类型。同样, 服务器不需要了解每个客户端的目的: HTTP 请求可以被孤立地考虑, 而不是与特定类型的客户端或预定的应用步骤序列相关联。其结果是一种可以在许多不同上下文中有效使用的协议, 并且其实现可以随时间独立演化。

HTTP 还被设计为一种中介协议 (intermediation protocol), 用于转换与非 HTTP 信息系统之间的通信。HTTP 代理 (proxies) 和网关 (gateways) 可以通过将其多样化的协议转换为超文本格式来提供对替代信息服务的访问, 该格式可以像 HTTP 服务一样被客户端查看和操作。

这种灵活性的一个后果是, 该协议不能根据接口背后发生的事情来定义。相反, 我们仅限于定义通信的语法 (syntax of communication)、接收到的通信的意图 (intent) 以及接收者的预期行为 (expected behavior)。如果孤立地考虑通信, 那么成功的操作应该反映在服务器提供的可观察接口的相应变化中。然而, 由于多个客户端可能并行操作, 甚至可能目的相反, 我们不能要求这些变化在单个响应的范围之外是可观察的。

本文档描述了 HTTP 中使用或引用的架构元素 (architectural elements), 定义了 "http" 和 "https" URI 方案, 描述了整体网络操作和连接管理 (connection management), 并定义了 HTTP 消息成帧 (message framing) 和转发要求 (forwarding requirements)。我们的目标是定义独立于消息语义的 HTTP 消息处理所需的所有机制, 从而为消息解析器 (message parsers) 和消息转发中介 (message-forwarding intermediaries) 定义完整的要求集。

1.1. Requirements Notation (要求符号)​

🇬🇧 English​

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Conformance criteria and considerations regarding error handling are defined in Section 2.5.

🇨🇳 中文​

本文档中的关键词 "MUST" (必须)、"MUST NOT" (绝对不能)、"REQUIRED" (必需)、"SHALL" (应)、"SHALL NOT" (不应)、"SHOULD" (应该)、"SHOULD NOT" (不应该)、"RECOMMENDED" (建议)、"MAY" (可以) 以及 "OPTIONAL" (可选) 应按照 [RFC2119] 中的描述进行解释。

一致性标准 (conformance criteria) 和有关错误处理的考虑因素在 Section 2.5 中定义。

1.2. Syntax Notation (语法符号)​

🇬🇧 English​

This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). Appendix B shows the collected grammar with all list operators expanded to standard ABNF notation.

The following core rules are included by reference, as defined in [RFC5234], Appendix B.1:

  • ALPHA (letters)
  • CR (carriage return)
  • CRLF (CR LF)
  • CTL (controls)
  • DIGIT (decimal 0-9)
  • DQUOTE (double quote)
  • HEXDIG (hexadecimal 0-9/A-F/a-f)
  • HTAB (horizontal tab)
  • LF (line feed)
  • OCTET (any 8-bit sequence of data)
  • SP (space)
  • VCHAR (any visible [USASCII] character)

As a convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical reasons.

🇨🇳 中文​

本规范使用 [RFC5234] 的 Augmented Backus-Naur Form (ABNF, 扩展巴科斯-诺尔范式) 符号, 并在 Section 7 中定义了列表扩展 (list extension), 允许使用 '#' 运算符紧凑地定义逗号分隔的列表 (类似于 '*' 运算符表示重复)。Appendix B 显示了将所有列表运算符扩展为标准 ABNF 符号的完整语法。

以下核心规则通过引用包含在内, 如 [RFC5234] 的 Appendix B.1 中所定义:

  • ALPHA (字母, letters)
  • CR (回车, carriage return)
  • CRLF (回车换行, CR LF)
  • CTL (控制字符, controls)
  • DIGIT (十进制数字 0-9, decimal 0-9)
  • DQUOTE (双引号, double quote)
  • HEXDIG (十六进制数字 0-9/A-F/a-f, hexadecimal 0-9/A-F/a-f)
  • HTAB (水平制表符, horizontal tab)
  • LF (换行, line feed)
  • OCTET (任意 8 位数据序列, any 8-bit sequence of data)
  • SP (空格, space)
  • VCHAR (任意可见的 [USASCII] 字符, any visible [USASCII] character)

按照惯例, 以 "obs-" 为前缀的 ABNF 规则名称表示出于历史原因而出现的 "过时的" (obsolete) 语法规则。

✅ Section 1 完成确认​

📍 翻译状态: Section 1 - Introduction 已完成

✓ 完成项:

  • ✅ 1:1 还原英文原文 (100% 完整)
  • ✅ 高质量中文翻译
  • ✅ 专业术语双语标注
  • ✅ ABNF 核心规则完整列出
  • ✅ 章节标题转换为链接格式

📊 内容统计:

  • 主章节: 1 个 (Introduction)
  • 子章节: 2 个 (1.1 Requirements Notation, 1.2 Syntax Notation)
  • ABNF 核心规则: 12 个完整定义
  • RFC 引用: 9 个 (RFC7231-7235, RFC2616, RFC2145, RFC2817, RFC2818)

⏭️ 下一步: Section 2 - Architecture (架构)

请回复 "继续" 以处理 Section 2。

Tags:
Last updated on