（转贴并修订，原翻译作者不详）
Network Working Group(网络工作组) R. Fielding
Request for Comments: 2616 UC Irvine
Obsoletes(过时弃用）: 2068 J. Gettys
Category: Standards Track （类别:标准组 ） Compaq/W3C
J. Mogul
Compaq
H. Frystyk
W3C/MIT
L. Masinter
Xerox
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
June 1999
超文本传输协议-HTTP/1.1
本备忘录状况
本文档说明了用于互联网社区的标准化跟踪协议，但还需要讨论和建议以便更
加完善。请参考"互联网官方协议标准"（STD1）来了解本协议的标准化状态。分发
散布本文是不受限制的。
版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
摘要
超文本传输协议（HTTP）是一种应用于分布式、协作式、超媒体信息系统的应
用层协议。它是一种通用的，状态无关的协议，可以用于除了超文本以外，还可以
通过扩展它的请求方法，错误代码和报头[47]来完成更多任务，比如名称服务和分
布对象管理系统。HTTP的一个特点是数据表示方式的典型性（typing）和可协商性，
允许建立独立于被传输数据的系统。
HTTP在1990年WWW全球信息刚刚起步的时候就得到了应用。本规范定义了HTTP/
1.1协议，这是RFC 2068的升级版[33]。
[页码1]
------------------------------------------------------------------------
目录
1 Introduction （介绍）...........................................7
1.1 Purpose（目的）..............................................7
1.2 Requirements （要求）.........................................8
1.3 Terminology （术语）..........................................8
1.4 Overall Operation （概述）...................................12
2 Notational Conventions and Generic Grammar（标志转换及通用语法）
.....................14
2.1 Augmented BNF （扩充的范式）.................................14
2.2 Basic Rules （基本规则）.....................................15
3 Protocol Parameters （协议参数）...............................17
3.1 HTTP Version （版本）........................................17
3.2 Uniform Resource Identifiers （统一资源标识）................18
3.2.1 General Syntax （通用语法）...............................19
3.2.2 http URL .................................................19
3.2.3 URI Comparison （URI对比）................................20
3.3 Date/Time Formats （时间日期格式）...........................20
3.3.1 Full Date （完整日期）....................................20
3.3.2 Delta Seconds ............................................21
3.4 Character Sets （字符集）....................................21
3.4.1 Missing Charset （不见了的字符集）........................22
3.5 Content Codings （内容编码）.................................23
3.6 Transfer Codings （传输编码）................................24
3.6.1 Chunked Transfer Coding （大块数据传输编码）..............25
3.7 Media Types （媒介类型）.....................................26
3.7.1 Canonicalization and Text Defaults .......................27
3.7.2 Multipart Types （复合类型）..............................27
3.8 Product Tokens （产品记号）..................................28
3.9 Quality Values （质量值）....................................29
3.10 Language Tags （语言标签）...................................29
3.11 Entity Tags （实体标签）.....................................30
3.12 Range Units （范围单位）.....................................30
4 HTTP Message （HTTP 消息）.....................................31
4.1 Message Types （消息类型）...................................31
4.2 Message Headers （消息头）...................................31
4.3 Message Body （消息主体）....................................32
4.4 Message Length （消息长度）..................................33
4.5 General Header Fields （通用头字段）.........................34
5 Request （请求）...............................................35
5.1 Request-Line （请求行）......................................35
5.1.1 Method （方法）...........................................36
5.1.2 Request-URI （请求-URI）..................................36
5.2 The Resource Identified by a Request ........................38
5.3 Request Header Fields （请求头字段）.........................38
6 Response （应答）..............................................39
6.1 Status-Line （状态行）.......................................39
6.1.1 Status Code and Reason Phrase （状态码和原因短语）........39
6.2 Response Header Fields （应答头字段）........................41
[页码2]
------------------------------------------------------------------------
7 Entity （实体）...................................................42
7.1 Entity Header Fields （实体头字段）..........................42
7.2 Entity Body （实体主体）.....................................43
7.2.1 Type （类型）.............................................43
7.2.2 Entity Length （实体长度）................................43
8 Connections （连接）...........................................44
8.1 Persistent Connections （持久连接）..........................44
8.1.1 Purpose （目的）..........................................44
8.1.2 Overall Operation（概述）.................................45
8.1.3 Proxy Servers （代理服务器）..............................46
8.1.4 Practical Considerations （实践中的考虑）.................46
8.2 Message Transmission Requirements （消息传送请求）...........47
8.2.1 Persistent Connections and Flow Control
（持久连接和流程控制）..................47
8.2.2 Monitoring Connections for Error Status Messages
（出错状态消息的监测连接）.........48
8.2.3 Use of the 100 (Continue) Status
（状态号100的使用）.........................48
8.2.4 Client Behavior if Server Prematurely Closes Connection
（如果服务器过早关闭连接，客户端的行为）.................50
9 Method Definitions （方法的定义）..............................51
9.1 Safe and Idempotent Methods （安全和幂等方法）...............51
9.1.1 Safe Methods （安全方法）.................................51
9.1.2 Idempotent Methods （幂等方法）...........................51
9.2 OPTIONS （选项）.............................................52
9.3 GET （命令：GET）............................................53
9.4 HEAD （命令：HEAD）..........................................54
9.5 POST （命令：POST）..........................................54
9.6 PUT （命令：PUT）............................................55
9.7 DELETE （命令：DELETE）......................................56
9.8 TRACE （命令：TRACE）........................................56
9.9 CONNECT （命令：CONNECT）....................................57
10 Status Code Definitions （状态码定义）........................57
10.1 Informational 1xx （报告：1XX）..............................57
10.1.1 100 Continue （100 继续）.................................58
10.1.2 101 Switching Protocols（交换协议）.......................58
10.2 Successful 2xx （成功：2XX）.................................58
10.2.1 200 OK （200 正常）.......................................58
10.2.2 201 Created （201 已建立）................................59
10.2.3 202 Accepted （202 已接受）...............................59
10.2.4 203 Non-Authoritative Information （无认证信息）..........59
10.2.5 204 No Content （无内容）.................................60
10.2.6 205 Reset Content （重置内容）............................60
10.2.7 206 Partial Content （部分内容）..........................60
10.3 Redirection 3xx （3XX 重定向）..............................61
10.3.1 300 Multiple Choices （复合选择）.........................61
10.3.2 301 Moved Permanently （永久转移）........................62
10.3.3 302 Found （找到）........................................62
10.3.4 303 See Other （访问其他）................................63
10.3.5 304 Not Modified （304 没有更改）.........................63
10.3.6 305 Use Proxy （305 使用代理）............................64
10.3.7 306 (Unused) （306 未使用）...............................64
[页码3]
------------------------------------------------------------------------
10.3.8 307 Temporary Redirect （暂时重定向）.....................65
10.4 Client Error 4xx （客户端错误）..............................65
10.4.1 400 Bad Request （错误请求）.............................65
10.4.2 401 Unauthorized （未认证）..............................66
10.4.3 402 Payment Required （支付请求）........................66
10.4.4 403 Forbidden （禁止）...................................66
10.4.5 404 Not Found （没有找到）...............................66
10.4.6 405 Method Not Allowed （方法不容许）....................66
10.4.7 406 Not Acceptable （不可接受）..........................67
10.4.8 407 Proxy Authentication Required （要求代理认证）.......67
10.4.9 408 Request Timeout （请求超时）.........................67
10.4.10 409 Conflict （冲突）....................................67
10.4.11 410 Gone （离开）........................................68
10.4.12 411 Length Required （长度请求）.........................68
10.4.13 412 Precondition Failed （预处理失败）...................68
10.4.14 413 Request Entity Too Large （请求的实体太大了）........69
10.4.15 414 Request-URI Too Long （请求URI太长了）...............69
10.4.16 415 Unsupported Media Type （不支持的媒提类型）..........69
10.4.17 416 Requested Range Not Satisfiable （请求范围未满足）...69
10.4.18 417 Expectation Failed （期望失败）......................70
10.5 Server Error 5xx （服务器错误 5XX）..........................70
10.5.1 500 Internal Server Error （内部错误）....................70
10.5.2 501 Not Implemented （未实现）............................70
10.5.3 502 Bad Gateway （错误网关）..............................70
10.5.4 503 Service Unavailable （服务不可用）....................70
10.5.5 504 Gateway Timeout （网关超时）..........................71
10.5.6 505 HTTP Version Not Supported （版本不支持）.............71
11 Access Authentication （访问认证）............................71
12 Content Negotiation （内容协商）..............................71
12.1 Server-driven Negotiation （服务器驱动协商）.................72
12.2 Agent-driven Negotiation （客户端驱动协商）..................73
12.3 Transparent Negotiation （透明协商）.........................74
13 Caching in HTTP （缓存）......................................74
13.1.1 Cache Correctness （缓存正确性）..........................75
13.1.2 Warnings （警告）.........................................76
13.1.3 Cache-control Mechanisms （缓存控制机制）.................77
13.1.4 Explicit User Agent Warnings （直接用户代理警告）.........78
13.1.5 Exceptions to the Rules and Warnings （规则和警告的异常）.78
13.1.6 Client-controlled Behavior（客户控制的行为）..............79
13.2 Expiration Model （过期模式）................................79
13.2.1 Server-Specified Expiration （服务器指定过期）............79
13.2.2 Heuristic Expiration （启发式过期）.......................80
13.2.3 Age Calculations （年龄计算）.............................80
13.2.4 Expiration Calculations （过期计算）......................83
13.2.5 Disambiguating Expiration Values （消除歧义的过期值）.....84
13.2.6 Disambiguating Multiple Responses （消除歧义的复合应答）..84
13.3 Validation Model （确认模式）................................85
13.3.1 Last-Modified Dates （最后更改日期）......................86
[页码4]
------------------------------------------------------------------------
13.3.2 Entity Tag Cache Validators （实体标签缓存确认）..........86
13.3.3 Weak and Strong Validators （强弱确认）...................86
13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates
当使用实体标签和最后更改日期字段时候的规则................89
13.3.5 Non-validating Conditionals （不可确认的条件）............90
13.4 Response Cacheability （应答缓存功能）.......................91
13.5 Constructing Responses From Caches （从缓存构造应答）........92
13.5.1 End-to-end and Hop-by-hop Headers （端对端和逐跳的头）....92
13.5.2 Non-modifiable Headers （不可以更改的报头）...............92
13.5.3 Combining Headers （组合报头）............................94
13.5.4 Combining Byte Ranges （组合字节范围）....................95
13.6 Caching Negotiated Responses （缓存协商过的应答）............95
13.7 Shared and Non-Shared Caches （共享和非共享缓存）............96
13.8 Errors or Incomplete Response Cache Behavior
（错误或不完整应答缓存行为）................97
13.9 Side Effects of GET and HEAD （GET和HEAD的单方影响）.........97
13.10 Invalidation After Updates or Deletions
（更新和删除后的失效）...................97
13.11 Write-Through Mandatory （强制写通过）.....................98
13.12 Cache Replacement （缓存替换）.............................99
13.13 History Lists （历史列表）.................................99
14 Header Field Definitions （头字段定义）......................100
14.1 Accept （接受）.............................................100
14.2 Accept-Charset （接受的字符集）.............................102
14.3 Accept-Encoding （接受的编码方式）..........................102
14.4 Accept-Language （接受的语言）..............................104
14.5 Accept-Ranges （接受的范围）................................105
14.6 Age （年龄，生存期）........................................106
14.7 Allow （容许）..............................................106
14.8 Authorization （认证）......................................107
14.9 Cache-Control （缓存控制）..................................108
14.9.1 What is Cacheable （什么可以缓存）.......................109
14.9.2 What May be Stored by Caches （什么将被缓存存储）........110
14.9.3 Modifications of the Basic Expiration Mechanism
基本过期机制的更改.........111
14.9.4 Cache Revalidation and Reload Controls
缓存重确认和重载控制..................113
14.9.5 No-Transform Directive （不可转换指示）..................115
14.9.6 Cache Control Extensions （缓存控制扩展）................116
14.10 Connection （连接）.......................................117
14.11 Content-Encoding （内容编码）.............................118
14.12 Content-Language （内容语言）.............................118
14.13 Content-Length （内容长度）...............................119
14.14 Content-Location （内容位置）.............................120
14.15 Content-MD5 （内容的MD5校验）.............................121
14.16 Content-Range （内容范围）................................122
14.17 Content-Type （内容类型）.................................124
14.18 Date （日期）.............................................124
14.18.1 Clockless Origin Server Operation （无时钟服务器操作）..125
14.19 ETag （标签）.............................................126
14.20 Expect （期望）...........................................126
14.21 Expires （过期）..........................................127
14.22 From （来自）.............................................128
[页码5]
------------------------------------------------------------------------
14.23 Host （主机）.............................................128
14.24 If-Match （如果匹配）.....................................129
14.25 If-Modified-Since （如果自从某个时间已经更改）............130
14.26 If-None-Match （如果没有匹配）............................132
14.27 If-Range （如果范围）.....................................133
14.28 If-Unmodified-Since （如果自从某个时间未更改）............134
14.29 Last-Modified （最后更改）................................134
14.30 Location （位置）.........................................135
14.31 Max-Forwards （最大向前量）...............................136
14.32 Pragma （语法）...........................................136
14.33 Proxy-Authenticate （代理鉴别）...........................137
14.34 Proxy-Authorization （代理授权）..........................137
14.35 Range （范围）............................................138
14.35.1 Byte Ranges （字节范围）...............................138
14.35.2 Range Retrieval Requests （范围重获请求）..............139
14.36 Referer （引用自）........................................140
14.37 Retry-After （一会重试）..................................141
14.38 Server （服务器）.........................................141
14.39 TE .......................................................142
14.40 Trailer （追踪者）........................................143
14.41 Transfer-Encoding（传输编码）..............................143
14.42 Upgrade （改良）..........................................144
14.43 User-Agent （用户代理）...................................145
14.44 Vary （变更）.............................................145
14.45 Via （经由）..............................................146
14.46 Warning （警告）..........................................148
14.47 WWW-Authenticate （WWW鉴别）..............................150
15 Security Considerations （对安全的考虑）.......................150
15.1 Personal Information（个人信息）........................151
15.1.1 Abuse of Server Log Information （服务日志信息的滥用）...151
15.1.2 Transfer of Sensitive Information （敏感信息传输）.......151
15.1.3 Encoding Sensitive Information in URI's
（对URI中的敏感信息编码）.................152
15.1.4 Privacy Issues Connected to Accept Headers
（可接受头的秘密问题）..............152
15.2 Attacks Based On File and Path Names
基于文件名和路径的攻击 .......................153
15.3 DNS Spoofing （DNS欺骗）....................................154
15.4 Location Headers and Spoofing （位置头和欺骗）..............154
15.5 Content-Disposition Issues （内容部署问题）.................154
15.6 Authentication Credentials and Idle Clients
（信用鉴定与空闲客户） ................155
15.7 Proxies and Caching （代理与缓存）..........................155
15.7.1 Denial of Service Attacks on Proxies
（对代理的服务拒绝攻击）....................156
16 Acknowledgments （致谢）.....................................156
17 References （参考）..........................................158
18 Authors' Addresses （作者地址）..............................162
19 Appendices （附录）..........................................164
19.1 Internet Media Type message/http and application/http
（网络媒体类型：消息/HTTP和应用/HTTP）......164
19.2 Internet Media Type multipart/byteranges
（网络媒体类型：多部分/字节范围）...................165
19.3 Tolerant Applications （容错的应用）........................166
19.4 Differences Between HTTP Entities and RFC 2045 Entities
（HTTP的实体和RFC2045中实体的区别）....167
[页码6]
------------------------------------------------------------------------
19.4.1 MIME-Version （MIME版本）................................167
19.4.2 Conversion to Canonical Form （语言形式转变）............167
19.4.3 Conversion of Date Formats （日期格式的转变）............168
19.4.4 Introduction of Content-Encoding （内容编码的介绍）......168
19.4.5 No Content-Transfer-Encoding （不要内容传输编码）........168
19.4.6 Introduction of Transfer-Encoding （传输编码的介绍）.....169
19.4.7 MHTML and Line Length Limitations
（MHTML与行长度限制）.......................169
19.5 Additional Features （附加的一些性质）......................169
19.5.1 Content-Disposition （内容部署）.........................170
19.6 Compatibility with Previous Versions （与久版本的兼容性）...170
19.6.1 Changes from HTTP/1.0 （自HTTP/1.0的更改）...............171
19.6.2 Compatibility with HTTP/1.0 Persistent Connections
（与HTTP/1.1持久连接的兼容性）......172
19.6.3 Changes from RFC 2068 （自RFC268的更改）.................172
20 Index （索引）...............................................175
21 Full Copyright Statement （完整版权声明）....................176
1 概述
1.1 目的
超文本传输协议（HTTP）是一种应用于分布式、合作式、多媒体信息系统的应
用层协议。在1990年WWW全球信息刚刚起步的时候HTTP就得到了应用。HTTP的第一个
版本叫做HTTP/0.9,是一种为了在互联网传输原始数据的简单协议。由RFC 1945[6]
定义的HTTP/1.0进一步完善了这个协议，它允许消息以类似MIME的格式传送，包含
有关数据传输的维护信息和关于请求/应答的句法修正。但是，HTTP/1.0没有充分考
虑到分层代理、高速缓存的作用以及对持久连接和虚拟主机的需求。并且，随着不
完善的应用程序的激增，HTTP/1.0迫切需要一个新的版本,以便使两个通信应用程序
能够确定彼此的真实性能。
本规范定义的协议为"HTTP/1.1"。这个协议与HTTP/1.0相比，要求更为严格，
以确保各项功能得到可靠实现。
实际的信息系统除了简单的取获外，还要求有更多的功能性，包括查找，前端
更新和注解。HTTP使用开放的方法集和报头集以指示请求[47]的目的。它是建立在
统一资源标识符(URI)[3]提供的地址(URL)[4]和名字(URN)上[20]，以指出方法应用
于哪个资源的。消息以类似于一种叫做多用途网络邮件扩展（MIME）[7] 的互联网
邮件的格式传递。
[页码7]
------------------------------------------------------------------------
HTTP也是用于用户代理及服务代理（网关）到其他网络系统的通用通信协议，
这样的网络系统可能由SMTP[16],NNTP[13],FTP[18],Gopher[2]和WAIS[10]协议支持。
这样，HTTP允许不同的应用程序对资源进行基本的超媒体访问。
1.2 要求
本文的关键词"必须", "绝对不可以", "要求", "最好", "最好不", "应该",
"不应该", "推荐", "可以", 和 "可选"将由RFC 2119[34]解释。
一个实现（具体应用）如果不能满足协议提供的一个或多个“必须”或“要求”等
级的要求，是不符合要求的。一个实现如果满足所有“必须”或“要求”等级以及所有
“应该”等级的要求，则可称为"绝对符合"的；若满足所有“必须”等级的要求但不能
满足所有“应该”等级的要求则被称为"部分符合"。
1.3 术语
本规范用到了若干术语，以表示HTTP通信中各参与者和对象扮演的不同角色。
“连接”（Connection）
为通信而在两个程序间建立的传输层虚拟电路。
“消息”(Message)
HTTP通信中的基本单元。它由一个结构化的八比特字节序列组成，与第4章定义
的句法相匹配，并通过连接得到传送。
“请求”(Request)
一种HTTP请求消息，参看第5章的定义。
“应答”(Response)
一种HTTP应答消息，参看第6章的定义。
[页码8]
------------------------------------------------------------------------
“资源”(Resource)
一种网络数据对象或服务，可以用第3.2节定义的URI描述。资源可以以多种表
现方式（例如多种语言，数据格式，大小和解决方案）或其他不同的途径获得。
“实体”(Entity)
作为请求或应答的有效负荷而传输的信息。一个实体包含报头形式的维护信息
和消息体形式的内容,由第7节详述.
“表示方法”(Representation)
一个应答包含的实体是由内容协商决定的，如第12章所述。一个特定的应答状
态所对应的表示方法可能有多个。
“内容协商”(Content Negotiation)
为“请求”服务时选择适当表示方法的机制，如第12节所述。任何应答里实体的
表示方法都是可协商的(包括出错应答).
“变量”（Variant)
在任何给定时刻，与一个资源对应的表示方法可以有一个或更多。每个表示方
法称作一个变量。使用变量这个术语并不一定意味着资源是由内容协商决定的。
“客户”（Client）
为发送“请求”而建立连接的程序.
“用户代理”(User agent)
能初始化“请求”的客户。常见的如浏览器，编辑器，蜘蛛(搜索引擎)，或其他
的终端用户工具。
“服务器”(Server)
接受连接以便通过发回应答为请求提供服务的应用程序。任何给定的程序都可
以既是客户端又是服务器；我们使用这些术语仅指特定连接中程序扮演的角色，而
不是指通常意义上程序的功能，同样，任何服务器都可以基于每个请求的性质转换
行为，扮演原服务器，代理，网关，或者隧道等角色。
[页码9]
------------------------------------------------------------------------
“原服务器”（Origin server)
给定的资源驻留或创建的地方.
“服务代理”（ Proxy）
一个既做服务器又做客户端的中介程序，其用途为其他客户发送请求，请求在
内部得到服务，或者经过可能的翻译后向前传递请求。一个代理服务器必须能同时
实现本规范中对客户和服务器要求。"透明代理"是一种除了代理要求的验证和鉴定
外不修改请求或应答的代理。"非透明代理"是一种修改请求或应答以便为用户代理
提供附加服务的服务代理，附加服务包括类注释服务，媒体类型转换，协议简化，
或者匿名滤除等。除非经明确指出，HTTP代理的“要求”对两种代理都适用。
“网关”（gateway）
为其他服务器充当中介的服务器。与代理服务器不同，网关接收请求，仿佛它
就是被请求资源所在的原服务器；提出请求的客户可能觉察不到它正在同网关通信。
“隧道”（tunnel）
一个在两个连接之间充当仅仅中继的中间程序。从启动时候起，隧道虽然可能
已经被HTTP请求初始化了，但它并被认为是HTTP通信的一方。当中继连接的两端都
关闭的时候，隧道就不再存在了。
“高速缓存”（Cache）
一个程序的应答消息的本地存储和控制此信息存储、检索和删除的子系统。一
个缓存存储可缓存的应答是为了减少以后对同样请求的应答时间和网络带宽消耗。
任一客户或服务器都可能包含一个高速缓存，但缓存不能应用于一个充当隧道的服
务器。
“可缓存”（Cacheable）
如果允许存储应答信息的一份拷贝以便运用于应答后继请求，这个应答就是可
缓存的。用来确定HTTP应答的可缓存能力的规则在13节中有定义。即使一个资源是
可缓存的，也可能在缓存能否将缓存的拷贝用于某特定请求一问题上存在附加的约
束。
[页码10]
------------------------------------------------------------------------
“直接，第一手的“（first-hand）
如果一个应答直接从原服务器而来，而没有经过不必要的服务代理的延迟，那
么应答就是直接（第一手的）的。如果它的有效性已经被原服务器直接认证，那么
这个应答也同样是第一手的.
”明确终止时间“（explicit expiration time）
原服务器指定的一个实体在无需进一步确认的情况下就不再被缓存返回的时间。
”启发式终止时间“（heuristic expiration time）
当没有”明确终止时间“可用时, 由高速缓存所指定的终止时间.
”年龄“（Age）
一个应答的年龄是从它被发送，或被原服务器成功确认到现在的时间.
”保鲜寿命“（Freshness lifetime）
一个应答生成和过期之间的时间长度。
”新鲜的“（Fresh）
如果一个应答的年龄还没有超过保鲜寿命，它就是新鲜的。
”陈旧的“（Stale）
一个应答的年龄已经超过了它的保鲜寿命，就是陈旧的。
”语义透明（semantically transparent）
当缓存的使用除了改善性能外既未影响请求客户机也未影响原服务器时，缓存
对于某特定的应答就是工作于语义透明方式了。当缓存语义透明时，客户收到的应
答恰好与原服务器直接处理请求后得到的应答相同（除了逐段转接的报头部分）。
“有效性判别器”（Validator）
用来查找一个缓存记录是否是一个实体的等效拷贝的协议元素。(例如,一个实
体标签（entity tag）或最终更改时间（Last-Modified time))。
“上游/下游”（upstream/downstream）
上游和下游描述了消息的流动：所有消息都从上游流到下游。
[页码11]
------------------------------------------------------------------------
“向内/向外”（inbound/outbound）
向内和向外指的是消息的请求和应答路径："向内"即"移向原服务器"，"向外"
即"移向用户代理".
1.4 概述
HTTP协议是一种请求/应答协议。 与主机建立连接后，客户以请求方法，URI
和协议版本的形式向服务器发送请求，继以类MIME信息，其中包括请求修订，客户
信息和可能的正文内容。服务器用状态行进行应答，这包括消息的协议版本和成功
或错误代码，后面是包括服务器信息，实体维护信息和可能的实体内容的类MIME消
息。HTTP和MIME之间的关系在附录19.4节中描述。
大部分的HTTP通信由用户代理引发，由对某原服务器上一个资源的请求构成。
最简单的情形，可以经用户代理（UA）和原服务器（O）之间的单一连接（v）完成。
请求链---------------------->
用户代理(UA)-------------单一连接（v)--------------原服务器（O）
<-----------------------应答链
当一个或多个中介在请求/应答链中出现的时候，会出现更复杂的情形。 常见
的中介形式有三种：服务代理，网关和隧道。服务代理是一种向前传送代理，它接
收绝对形式的URI请求，重写全部或部分消息，然后把重新格式化后的请求发送到URI
确定的服务器上。网关是一种接收代理，它充当其他服务器的上层，如果必要的话，
它将请求翻译为下层服务器的协议。隧道不改变消息而充当两个连接之间的中继点；
它应用于通信需要穿过中介（如防火墙），而中介甚至不能理解信息内容的时候。
请求链-------------------------------------->
UA-----v-----A-----v-----B-----v-----C-----v-----O
<-------------------------------------应答链
上图显示了用户代理和原服务器之间的三个中介（A，B和C)。请求或应答消息
游历整条链的时候需通过四个独立的连接。这个特性很重要，因为某些HTTP通信选
项只能应用于到最近的非隧道邻居，链的终点的连接，或者沿着链的所有连接。图
表尽管是线性的，每部分可能都在忙于多路同时通信。例如，B可以接收来自不同于
A的许多客户的请求，并且/或者转送到不同于C的服务器，与此同时，它还在处理A
的请求。
[页码12]
------------------------------------------------------------------------
任何非隧道的通信成员都可以使用内部的缓存来处理请求。高速缓存的作用是
如果沿着链的一个成员对请求采用了高速缓冲的应答，请求/应答链就会大大缩短。
以下图解作为结果产生的链，假定B拥有来自O（通过C）的一个从前应答的备份，
请求尚未被UA或A缓存。
请求链---------->
UA-----v----------A-----v-----B-----C----O
<---------应答链
并不是所有的应答都能有效地缓存，一些请求可能含有修改量，对缓存动作有
特殊的要求。缓存动作和缓存应答的HTTP要求将在第13节定义。
实际上，目前万维网上有多种结构和配置的高速缓存和代理被实验或使用。这
些系统包括节省越洋带宽的国家级代理缓存层，广播或多点通信缓存接口，通过
CD-ROM分配缓存数据子集的机构，等等。HTTP系统应用在宽频带连接的企业局域网
中，通过PDA的低耗无线连接和间歇式连接访问。HTTP1.1的目标是支持各种各样的
应用配置，引进协议结构以满足那些需要较高可靠性，可以排除故障或至少指示故
障的网络应用的要求。
HTTP通信在通常发生在TCP/IP连接上。默认端口是TCP 80，不过其它端口也可
以使用。这并不妨碍HTTP在其他因特网协议或者其他的网络上实现。http仅仅期望
可靠的传输；任何提供这种保证的协议都可以使用；HTTP/1.1请求和应答结构在某
（传输）协议上的传输数据单元映象问题已经不在本规范的讨论范围之内。
[页码13]
------------------------------------------------------------------------
在http/1.0中，大部分的实现为每个请求/应答交换使用了新连接。而http/1.1
中，一个连接可以用于一个或更多请求/应答交换，虽然连接可能会因为各种原因中
断（见第8.1节）。
2 符号惯例和一般语法
2．1 扩充BNF
本文档规定的所有机制都用两种方法描述：散文体（prose)和类似于RFC 822的
扩充范式(BNF)。要理解本规范，使用者需熟悉符号表示法。扩充BNF包括下列结构：
名字 = 定义
一条规则的名字仅仅是名字本身（没有任何"<"和">"），由等号"="把它和后面
的定义分离开。只有空格是用来缩排后续行，以表示定义的规则多于一行时，空格才
是真正重要的。一些基本规则使用了大写字母，如SP，LWS，HT，CRLF，DIGIT，ALPHA，
等等。无论何时，如果加上尖括号会有利于识别规则名字，就可以在定义的范围内
使用。
"文字"
文字原文使用引号。除特殊情况，原文对外界不敏感。
规则1 | 规则2
由竖线("|"）分开的元素是可选的，例如，"yes | no"表示yes或no都是可接受
的。
（规则1 规则2）
围在括号里的多个元素视作一个元素。这样"(elem (foo | bar) elem)"允许标
记序列"elem foo elem"和elem bar elem"。
* 规则
"*" 放在元素前表示重复。完整的形式是"
*元素"，表示元素至少出现
次，至多出现次。默认值是0和无穷大，所以"*(元素)"允许任何数值，包括零；
"1*元素"至少需要一次；"1*2element"允许一次或两次。
[规则]
方括号里是任选元素；"[foo bar]"相当于"*1(foo bar)".
[页码14]
------------------------------------------------------------------------
N 规则
特殊的重复："(元素)"相当于"*(元素)"； 也就是说，(元素)正好出
现了次。这样2DIGIT是一个两位数字，3ALPHA是一个由三个字符组成的字符串。
#规则
类似于"*",结构"#"是用来定义一系列元素的。完整的形式是"#元素,表
示至少个元素，至多个元素，元素之间被一个或多个逗号(",")以及可选的线
性空白区(LWS)隔开了。这就使得列表的一般形式变得非常容易；像
( *LWS element) *( *LWS ","*LWS element ))
就可以表示为
1#element
无论在哪里使用这个结构，空元素都是容许的，但是不计入元素出现的次数。换句
话说，"(元素), , (元素) "是允许的，但是仅仅视为两个元素。因此，在至少需要
一个元素的地方，必须存在至少一个非空元素。默认值是0和无穷大，这样，
"#element"允许任何数字，包括零；"1#element"至少需要1个元素
；"1#2element"允许1个或2个元素。
；注释
用分号引导的注释，从规则正文的右边一段距离开始直到行尾。这是做注释的
简单方法，注释与说明是同样有用的。
隐含 *LWS
范式文法所描述的语法是基于字的。除非特别注明，线性空白可出现在任何两个
相邻字之间（标记或引用字符串），以及相邻字和间隔符之间，并不改变一个域的含
义。任何两个标记之间（下面会对"token(标记)"进行定义）必须有至少一个分割符，
否则将会被理解为单一标记。
2．2基本规则
下面的规则描述了基本的解析结构，贯穿于本规范的全文。US-ASCII(美国信息
交换标准码)字符规定是由ANSI X3.4-1986[21]定义的。
[页码15]
------------------------------------------------------------------------
OCTET = <任意八比特的数据序列>
CHAR = <任意ASCII字符（八进制 0-127）>
UPALPHA = <任意大写字母"A"..."Z">
LOALPHA = <任意小写字母"a"..."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <任意数字0，1，...9>
CTL = <任意控制字符(octets 0 - 31)及删除键DEL（127）>
CR =
LF =
SP =
HT =
<"> =
HTTP/1.1将CR LF的顺序定义为除了报文以外任何协议元素的行尾标志（宽松应
用见附录19.3）。报文内部的行尾标志是由它的关联媒体类型定义的，如3.7节所述。
CRLF = CR LF
如果延续行由空格或水平制表开始，HTTP/1.1 的报头字段值可以折叠到到多行
上。所有的线性空白，包括折叠，具有同SP一样的语义。接收者在解释域值或将消息
转送到下游时可以用单个SP替代任何线性空白。
LWS = [CRLF] 1*( SP | HT )
文本规则仅仅适用于描述字段的内容和不会被消息语法分析程序解析的值。
*TEST的字可以包含ISO-8859-1[22]里的字符，也可以包含字符规定里的字符[14]。
TEXT = <除CTLs以外的任意OCTET，但包括LWS>
一个CRLF仅仅在作为报头字段延续的一部分时才在TEXT定义里允许使用。并且
最好折叠的LWS会在文本分析前被单个的空格所取代。
十六进制数字字符用在数个协议元素里。
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
[页码16]
------------------------------------------------------------------------
许多HTTP/1.1的报头字段值是由LWS或特殊字符分隔的字构成的。这些特殊字符
必须包含在引用字符串里，方可用在参数值（如3.6节定义）里。
token （标记） = 1*<除CTLs与分割符以外的任意 CHAR >
separators（分割符） = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
用圆括号括起来的注释可以包含在一些HTTP报头字段里。只有作为域值定义的一
部分时注释才是允许的。在其他域里，圆括号视作字段值的一部分。
comment （注释）= "(" *( ctext | quoted-pair | comment ) ")"
ctext = <除"(" and ")"以外的任意TEXT >
一个文本字符若在双引号里，则当作一个字。
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <除<">以外的任意TEXT >
反斜线("\")可以用作单一字符引用结构，但仅在引号字符串或注释里。
quoted-pair = "\" CHAR
3 协议参数
3.1 HTTP版本
HTTP使用"<主要>.<次要>"的编号方案表示协议版本。协议的版本方针是希望允
许发送者表示消息的格式和性能以便理解更深一层的HTTP通信， 而不仅仅是当前通
信获得的特征。消息构件的增加不影响通信动作，或仅仅增加了扩展域值，版本号并
没有因此变化。协议的改变增加了一些特征，没有改变一般的消息解析规则，但是增
加了消息的语义或者暗含了发送者新增的功能，这时<次要>数字便要增大。当协议的
消息格式改变时，<主要>数字增大。
[页码17]
------------------------------------------------------------------------
HTTP消息的版本在消息的第一行HTTP-版本字段里表示。
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
注意主要和次要数字必须看作是两个分离的整数，二者都可以增加到比单位数
还大。这样，HTTP/2.4的版本比HTTP/2.13低，依次HTTP/2.3的版本比HTTP/12.3低。
首位的零必定被接收者忽视，一定不要发送。
一个发送包含HTTP版本"HTTP/1.1"的请求或应答消息的应用，必须至少有条件
的服从本规范。至少有条件服从本规范的应用应该在消息里使用"HTTP/1.1"的HTTP
-版本，任何与 HTTP/1.0不兼容的消息则必须这样做。关于何时发送特殊的HTTP-版
本值，更多资料请参看RFC 2145[36].
一项应用使用了某HTTP版本，则这此版本应是它至少有条件服从的最高HTTP版本.
服务代理和网关转送的消息的协议版本与应用版本不同时，需要小心。既然协议
版本表示发送者的协议性能，代理/网关一定不能发送标示版本高于它本身的实际版本
的消息。如果收到更高版本的请求，代理/网关必须降低请求的版本，或者发出出错应
答，或者切换到隧道动作。
由于自RFC 2068[33]发布后发现的HTTP/1.0代理协同工作问题，高速缓存代理必须，
网关可以，隧道必须不将请求提升到它们支持的最高版本。代理/网关的应答的主要版
本号必须同请求相同。
注：HTTP版本的转换可能会包含相关版本必需或禁止的报头字段修改。
3.2 统一资源标识符（URI）
URI的许多名字已为人所知：WWW地址，通用文件标识符，通用资源标识符[3]，
以及最后统一资源定位器(URL)[4]和统一资源名称(URN)[20]的结合。只要与HTTP相
关，统一资源定位器只是格式化的字符串，它通过名称，地址，或任何别的特征确定
了资源的位置。
[页码18]
------------------------------------------------------------------------
3.2.1 一般语法
根据使用时的上下文，HTTP里的URI可以表示成绝对形式或基于已知的URI的相
对形式。两种形式的区别是根据这样的事实：绝对URI总是以一个主题名字作为开头，
其后是一个冒号。关于URL更详尽的信息请参看"统一资源标识符(URI):一般语法和
语义",RFC 2396 [42](代替了RFCs 1738 [4]和RFC 1808 [11])。本规范采用那份规
范里关于"URI-参考","绝对URI","相对URI","端口","主机","绝对路径"和"认证"
的定义.
HTTP协议不对URI的长度作事先的限制。服务器必须能够处理它们服务的任何资
源的URI，并且应该能够处理无限长度的URI。如果它们提供可以产生这种URI的基于
GET的形式。服务器在一个URI长度超过它能处理的范围时，应该返回414（URI太长）
状态值。(见 10.4.15小节)
注:服务器在依赖长于超过255字节的URI时应谨慎，因为一些旧的客户或服务代
理的实现可能不支持这些长度.
3.2.2 http URL
“http”主题用来通过HTTP协议定出网络资源的位置。本节为HTTP的URL定义了这
种主题相关的语法和语义.
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
如果端口为空或未给出，就假定为80。语义即：已识别的资源放在服务器上，
在那台主机的那个端口上监听TCP连接，对资源的请求的URI为绝对路径(5.1.2节)。
无论什么时候，都应该避免在URL里使用IP地址(参看RFC 1900 [24])。
如果绝对地址没有出现在URL里，它用作对资源的请求的URI时必须作为"/"给出。
如果代理收到主机名不是一个资格充分域名的，它可以为收到主机名加上域名。
如果代理收到一个资格充分的域名，一定不能改变主机名。
[页码19]
------------------------------------------------------------------------
3.2.3 URI 比较
当比较两个URI是否匹配时，客户应该对整个URI进行区分大小写，以八字节为
单元的比较。以下情况例外：
1）一个为空或未给定的端口等同于那个URI索引里的默认端口;
2）主机名的比较必须是不区分大小写的;
3）主题名（“HTTP”）的比较必须是不区分大小写的;
4）一个空绝对路径等同于绝对路径"/"。
除了"保留"或"危险"集里的字符(参见RFC 2396 [42])，字符等同于它们的""%" HEX HEX"编码.
例如,以下三个URI是等同的:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
3.3 日期/时间格式
3.3.1 完整日期
历史上的HTTP应用一直允许三种不同的表示日期/时间戳的格式:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
第一种格式是作为Internet标准提出来的,它表示一个由RFC 1123 [8](RFC 822[9]
的升级版本)定义的固定长度的子集。第二种格式使用比较普遍，但是基于废弃的
RFC 850 [12]，需要(应该)用四位数表示年份。对日期值进行语法分析的HTTP/1.1
客户和服务器必须接受所有三种格式(为了同HTTP/1.0兼容)，虽然它们必须只产生
RFC 1123格式以在报头字段里表示HTTP日期值。（在小节19.3中可以看到更多信息）
注:鼓励日期值的接收者在接受可能由非HTTP应用发来的日期值时要健壮，因为
这种非HTTP应用有时是通过服务代理/网关向SMTP和NNTP检索或发送消息的。
[页码20]
------------------------------------------------------------------------
所有的HTTP日期/时间戳都必须毫无例外的以格林威治平均时间(GMT)表示。这
是为了HTTP，GMT完全等同于UTC(协调世界时间)。这在前两种形式里用三个字母的
时区缩写-GMT的蕴含来表示，并且读取ASC时间格式时必须先被假定。HTTP日期区分
大小写，除了在语法中作为SP特别包括的LWS外，一定不能包括额外的LWS。
HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
weekday = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"
注意:HTTP对日期/时间戳格式的请求仅仅应用在协议流里。客户和服务器不必
为了用户表示，请求记录及其他而使用这些格式.
3.3.2 Delta秒
一些HTTP报头字段收到消息后，允许以十进制整数秒表示的时间值。
delta-seconds = 1*DIGIT
3.4 字符集
HTTP使用的关于术语"字符集"的定义和MIME中所描述的一样.
[页码21]
------------------------------------------------------------------------
本文档中的术语"字符集"指一种用一个或更多表格将一个八字节序列转换成一
个字符序列的方法。注意另一方向的无条件转换是不需要的，在这种转换里，并不
是所有的字符都能在一个给定字符集里得到，并且字符集可能提供多个八进制序列
表示一个特定字符。这个定义将允许各种字符编码方式，从简单的单表格映射如
US-ASCII到复杂的表格交换方法如ISO-2022的技术里所使用的。然而，与MIME字符
集名字相关联的定义必须充分说明从八字节变换到字符所实现的映射。特别的，使
用外部轮廓信息来决定精确映射是不允许的.。
注:这里使用的术语"字符集"更一般的被称作一种"字符编码"。不过，既然HTTP
和MIME使用同样的注册表，共用术语是很重要的。
HTTP字符集用不区分大小写的标记表示。完全标记集合由IANA字符集注册表[19]
定义。
charset = token
尽管HTTP允许用任意标记作为字符集的值，任何在IANA字符集注册表里有预先
确定值的标记必须表示该注册表定义的字符集。对那些IANA定义的字符集，应用应
该限制使用字符集。
实现者应该注意IETF字符集的要求[38][41].
3.4.1 失踪字符集
一些HTTP/1.0软件将没有字符集参数的内容类型报头错误的理解为"接收者应该
猜猜。"若发送者希望避免这种情况，可以包含一个字符集参数，即使字符集是
ISO-8859-1；当知道这样不会使接收者混淆以后，应该这样做。
不幸的是，一些旧的HTTP/1.0不能适当处理详细的字符集参数。HTTP/1.1接收
者必须重视发送者提供的字符集标注；当最初显示文档时，那些提供"猜"字符集服
务的用户代理必须使用内容类型域中的字符集，如果它们支持那个字符集，而不是
接收者的首选项。（参看3.7.1节）
[页码22]
------------------------------------------------------------------------
3.5 内容编码
内容编码值表示一种已经或可以应用于实体的编码变换。内容编码主要用来允许
文档压缩，换句话说，有效的变换而不损失它的基本媒体类型的特性，也不丢失信息。
经常地，实体以编码形式储存，直接传送，只能由接收者译码.
content-coding = token
所有内容编码值都是不区分大小写的。HTTP/1.1在接收译码字段(14.3节)和内容
译码字段(14.11节)的报头字段里使用内容编码值。尽管该值描述了内容编码，更重要
的是它指出需要什么机制来解码。
互联网赋值机构(IANA)充当内容编码值标记的注册处。最初，注册表包含下列标记:
gzip（GUNzip压缩文件）
一种由文件压缩程序"gzip"(GNU zip)---如RFC 1952所描述---生成的编码格式。
这种格式是一种32位CRC Lempel-Ziv编码(LZ77)。
compress（压缩）
由通用UNIX文件压缩程序"compress"生成的编码格式。这种格式是一种具有可
适应性的Lempel-Ziv-Welch编码。对未来的编码来说，用程序名识别编码格式是不可
取。在这里他们的用处是作为历史实践的代表而不是好的方案。为了同以前的HTTP实
现相兼容，应用应该将"x-gzip"和"x-compress"分别等同于"gzip"和"compress"。
deflate（缩小）
RFC 1950 [31]定义的"zlib"格式与RFC 1951 [29]描述的"deflate"压缩机制的
组合。
[页码23]
------------------------------------------------------------------------
Identity（标识）
缺省(标识)编码；无论如何，不进行转化的应用。这种内容译码仅被用于接受
译码报头，并且不能被用在内容编码报头。
新的内容译码值的标记应该注册；为了允许客户和服务器间的互用性，内容译
码运算的规范需要实现一个可被公开利用并能独立实现的新值，并且与这节中内容
译码定义的目的相一致。
3.6 传输编码
传输编码值被用来表示一个已经能够，或可能需要应用于一个实体的编码转化，
为的是能够确保通过网络安全传输。这不同于内容译码，传输译码是消息的特性而
不是原始实体的特性。
transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" parameter )
参数采用属性/值对的形式.
参数 = 属性 "=" 值
属性 = 标记
值 = 标记 | 引用-串（quoted-string）
所有传输译码值是大小写不敏感的。HTTP/1.1在TE报头字段(14.39节)和传输译
码报头字段(14.41节)运用传输译码。
无论何时一个传输译码都被应用于一个消息体，传输译码的设置必须包括"大块"，
除非消息被结束连接停止。当"大块"传输译码被应用时，它必须是应用于消息体的
最后传输译码。并且对消息主体使用“大块”编码方式不能超过一次。这些规则让接
收者确定消息的传输长度(4.4节)。
传输译码与MINE[7]的内容传输译码值相类似,它被设计为在7BIT的传输服务上
安全传输二进制数据。不过，安全传输对纯8位传输协议有不同的焦点。在HTTP中，
消息体唯一不安全的特性是确定准确的主体长度这个难点(7.2.2节)，或在共享传输
上加密的要求。
[页码24]
------------------------------------------------------------------------
网络分配数字权威(IANA)担任了传输译码值标记注册处的角色。起初，注册包
含如下标记:大块"chunked"(3.6.1节)，"identity"身份(3.6.2节)，"gzip"(3.5节),
"compress"(3.5节)，和"deflate"(3.5节).
新的传输编码值标记应和新的内容编码值标记以相同的方式注册(3.5节)。
服务器接收到一个不能理解的传输译码实体时应返回501(未实现)，并且关闭连接。
服务器不能向HTTP/1.0客户发送传输译码。
3.6.1 成块传输编码（Chunked Transfer Coding）
成块编码更改消息主体，为的是将它以一系列大块的形式传送，每一个连同它自
己尺寸的指示器，后面跟随一个可选的trailer，里面包含着entity-header字段。这
允许动态的生成将和必须的信息一起被传送的内容，必须的信息是为了让接收者确认
他已经获得全部消息。
Chunked-Body = *chunk
last-chunk
trailer
CRLF
chunk = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF
chunk-size = 1*HEX
last-chunk = 1*("0") [ chunk-extension ] CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF)
大块尺寸域是用16进制表示大块尺寸的一串数字。成块编码以任一尺寸为0的大
块结束，后面是trailer，以一个空行终止.
trailer允许发送者在消息末尾包含附加的HTTP报头字段。trailer头字段可
被应用于表示说明包含于trailer的HTTP报头字段 (14.40节)
[页码25]
------------------------------------------------------------------------
一个服务器在应答中使用了”大块“传输译码时不能在任何报头字段使用trailer，
除非以下至少一条为发生:
a)请求包括一个TE报头字段，表明"trailer"在应答的转移译码中是可被接受的，
就像14.39节中描述的那样。
b)服务器是应答的原始服务器。trailer的域完全由可选的元数据构成，这个接
收者可以在不接受这个元数据的情况下使用消息(在一个原始服务器可接受的方式中)。
换句话说，原始服务器愿意接受trailer域可能会在通往客户的通道上被默默放弃的
这种可能性。
当消息被一个HTTP/1.1服务代理接收，并且转发给一个HTTP/1.0接收者时，这种
需要求防止了一个互用性的失误。它避免了一个依据协议将使在服务代理上必须安置
一个可能无限大的缓冲器情形发生。
对一个大块主体进行解码处理的例子已在附录19.4.6中作过介绍。
所有HTTP/1.1应用程序必须能接受和解码"大块"传输译码，并且必须忽略它们不
理解的大块扩展扩展名。
3.7 媒体类型
为了提供公开的，可扩展的数据输入和类型协商，HTTP在Content-Type(14.17节)
和Accept(14.1节)报头字段中运用网络媒体类型.
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
参数可能在属性/值的形式上遵循类型/亚类型。(如3.6节定义)
类型，子类型，和参数属性名称是大小写不敏感的。参数值敏感与否，取决于
参数名称的意义。线性空白区(LWS)不能被用于类型和子类型之间，也不能用于一种
属性和他的值之间。一个参数存在与否对媒体类型的处理可能有重要意义，这取决
于它在媒体类型注册中的定义。
如果不能改变自己，那么就努力改变世界！
报告
[广告]
robinfoxnan
秀才
UID 19596
精华 0
积分 250
帖子 10
威望 45 点
金钱 85 元
阅读权限 100
注册 2006-3-27
状态 离线 #3 中 小
发表于 2006-3-28 01:11 资料 短消息 加为好友
26-32页，速度有点慢了，170多页呢，靠
[页码26]
------------------------------------------------------------------------
注意：一些旧的HTTP应用不能识别媒体类型参数。向一个旧的HTTP应用传送数
据时，应该仅当被要求使用类型/子类型定义时候，才发送媒体类型参数。
媒体类型值已经在网络分配数码权威(IANA[19])注册。媒体类型的注册程序在
RFC 1590[17]中略述。不鼓励使用未经注册的媒体类型。
3.7.1 规范化和原文缺省
网络媒体类型以语言的典型形式注册。一个通过HTTP消息传输的实体必须在传
送前就已经使用适当的语言规范形式说明过了，"text"类形除外，就像下段定义的
那样。
当在规范的形式中，"text"类型的媒体子类型使用CRLF作为行的结束。HTTP放
松了这个要求，当一个完整实体传输完成时，允许传送的"text"媒体以简单的CR或
LF独立作为一行的结束符。HTTP应用程序必须接受CRLF，单个CR，和单个LF在通过
HTTP接收的文本媒体中作为行结束符号。而且，如果文本使用了一个字符集，而字
符集没有分别用字节13和10表示CR和LF，比如有些多字节的字符集（译：UTF8等）。
HTTP允许使用那种字符集定义的等同CR和LF的任何字节序以表示行结束。这个关于
行结束的灵活性仅仅应用于一个实体主体中的文本媒体； 一个单独CR或LF在任意
HTTP控制结构中都绝对不能代替CRLF。(例如报头字段和多部边界)。
如果一个“实体主体”使用一种“内容编码”方式进行编码，则后面的数据必须使
用前面定义好的形式进行编码。
"charset"（字符集）参数和一些媒体类型一起使用用来定义数据的字符集(见
3.4节)。当发送者没有提供清楚的charset参数，通过HTTP接收数据时，"text"类型
的媒体子类型就被定义成有一个值为"ISO-8859-1"的默认"charset"。数据在不同于
"ISO-8859-1"或它子集的字符集中，必须被标以适当的"charset"值。 参见3.4.1节
中兼容性问题。
3.7.2 多部分类型（Multipart type)
MIME提供了很多"多重部分"类型，--在单个消息体内封装一个或多个实体。所
有的多重部分类型共享一个通用语法，就像RFC 2046[40]的5.1.1节中定义的那样。
[页码27]
------------------------------------------------------------------------
并且必须包括一个作为媒体类型值一部分的边界参数。这个消息体自成为一个
协议元素，因此在主体两部分间必须只能用CRLF来表示行结束。不同于RFC 2046，
任一多重消息的末尾必须为空；HTTP应用程序不能传送末尾(即使原始的多重部分包
含一个末尾)。存在这些制约是为了保护一个多重部分消息实体的固有本质，而结束
多重部分边界已经在消息体的"结尾"加以表明。
通常，HTTP将一个消息体视为与任何其他媒体类型无异，严格如负载。当它出
现在206应答时，会有一个例外："多重部分/字符串"类型(附录19.2)，它将会被一
些HTTP缓存机制解释，就像13.5.4和14.16节中描述的那样。除此情况外，一个HTTP
用户代理在接收多重部分类型时，应该遵循与一个MINE用户代理相同或相似的行为，
一个多重部分消息体中每一个部分的MIME头字段，如果超越了MIME定义的语义，则
它对HTTP没有任何意义。
通常，一个HTTP用户代理在接收多重部分类型时，应该遵循与一个MINE用户代
理相同或相似的行为。如果一个应用程序收到一个不能识别的多重部分的子类型，
这个应用程序必须视它与"multipart/mixed"（多重部分/混合）等价。
注："多重部分/形态-数据"形式已被明确定义，这种携带形式的数据适合通过
POST请求方法处理，正如RFC 1867[15]中所描述的.
3.8 产品标记
通过软件名和版本，产品标记被通讯应用软件用来识别自己。多数领域还把产
品标记用空格分开，用于列举成为应用程序重要部分的子产品。按惯例，列举出产
品的顺序是为了识别应用软件的重要性。
product = token ["/" product-version]
product-version = token
例:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
[页码28]
------------------------------------------------------------------------
产品标记应言简意赅。它们不能用来做广告或其他不重要的信息。虽然任一标
记字符都可以出现在产品-版本上，但这个标记应该仅被用来做一个版本标识(同类
产品中成功的版本仅区别在产品价值的版本部分）。
3.9 质量值(Quality Values)
HTTP内容协商(12节)运用简短的"浮点"数字来表明不同可协商参数之间的相关
重要性("权值")。权值可以是一个从0到1的规格化了实数，0是最小值，是最大值。
如果参数是个为0的质量值，那么这个参数的内容不被客户接受。HTTP/1.1应用软
件不可以在小数点后产生多于三位的数字。这些值的用户配置也应受限于这种方式。
qvalue = ( "0" [ "." 0*3DIGIT ] )
| ( "1" [ "." 0*3("0") ] )
"质量值" 是一个不当的用词，因为这些值仅仅表现想要得到的质量的相对的
降级程度。
3.10 语言标签
一个语言标签和自然语言一样，用来说、写、或被人用来与其他人传递信息。
计算机语言明显不包括在内。HTTP在Accept-Language 和Content-Language字段内
使用语言标签。
HTTP语言标签的语法和注册和RFC 1766[1]中定义的一样。总之，一个语言标签
是由一部分或多部分构成：一个主要语言标签和可能为空的一系列下子标签：
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
标签中不允许出现空格，标签对大小写不敏感。由IANA来管理语言标签中的命
名空间。典型的标签包括:
en, en-US, en-cockney, i-cherokee, x-pig-latin
[页码29]
------------------------------------------------------------------------
任何两个字母的主标签都是一个ISO-639语言的缩写，两个大写字母的子标签是
一个ISO-3166的国家代码。(上面的最后三个标签是未经注册的标签；除最后一个之
外所有都是可在将来注册的例子标签)。
3.11 实体标签
实体标签用来从相同请求资源中比较两个或更多实体。HTTP/1.1在Etag(14.19
节)，If-match(14.24节)，If-None-match(14.26节)，和If-rang(14.27节)报头字
段中运用实体标签。关于它们怎样像缓存确认一样使用和比较的定义在13.3.3节中。
一个实体标签由一个不透明的带引号的字符串组成，可能带一个虚弱指示器的前缀。
entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
在两个实体逐字节相等时，一个"健壮的实体标签"可以被使用同一资源的两个
实体共享。
一个"虚弱(weak)的实体标签"，由"W/"前缀表示，在实体相等且可以互相替代
而在语义上不发生重大的变动时，可以会被使用同一资源的两个实体共享。一个弱
实体标签只能在弱对比时使用。
一个实体标签必须在所有与一个特殊资源相连系实体的版本中是独一无二的。
一个给定的实体标签值可以用于不同的URI请求获得的实体，但相同实体标签值与不
同URI请求获得的实体结合的使用方式，不意味着那些实体的等同。
3.12 范围单位(Range Units)
HTTP/1.1允许一个客户请求获得应答实体中的一部分。HTTP/1.1在“Range”（
范围）(14.35节)和“Content-Range”（内容范围）报头字段(14.16节)运用范围单位。
一个实体可根据不同的结构单位分解成子区域.
range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token
HTTP/1.1中定义的唯一的范围单位是"byte"。HTTP/1.1实现时可能忽略使用其
他单位指定的范围。
[页码30]
------------------------------------------------------------------------
HTTP/1.1的设计允许应用软件不依靠有关“范围”的知识而实现。
4 HTTP消息
4.1 消息类型
HTTP消息由从客户到服务器的请求和从服务器到客户的应答组成.
HTTP-message = Request | Response ; HTTP/1.1 messages
请求(第5节)和应答(第6节)的消息是用一般的消息格式RFC 822[9]来传输实体的
(消息的有效载荷)。这两种消息都是由开始行，零或者更多的报头字段(也叫做头)，
象征头结束的空行(譬如说只有回车换行字符的行)组成，有时可能会有一个信息体。
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
为了健壮性，服务器必须在期望收到请求行的地方忽略任何接收到的空行。
换句话说，如果服务器在读一条信息开始的协议流时先收到了CRLF，它必须忽略这
个CRLF。
某个有问题的HTTP/1.0客户端在POST请求后会产生额外的CRLF。为了重述什么
是BNF明确禁止的，一个HTTP/1.1客户端不可以在请求的前面和后面加多余的CRLF。
4.2 消息头
HTTP报头字段包括常规头(4.5节)，请求头(5.3节)，应答头(6.2节)和实体头
(7.1节)字段。它们遵循RFC822[0]3.1节中给出的同一个常规的格式。每一个报头
字段由名字、紧跟一个冒号":"和域值构成。域名是大小写不敏感的。尽管单个的
SP是首选的，域值前还是可能有任意LWS。报头字段能通过把各个额外行(至少有一
个SP或HT)前置来扩展一行为多行。当产生HTTP结构时，应用程序必须遵循"共同格
式"，因为这可能存在一些实现，不能接受超越共同规范的任何东西。
[页码31]
------------------------------------------------------------------------
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
这个域的内容不包括任何前缀或后缀的的LWS：线形空白区出现在field-value
第一个非空格字符前或出现在field-value最后一个非空格字符的后面。去掉这些前
缀或后缀的LWS可以去掉，而不会影响field-content的意思。 在解析字段值的时候
或者向下游推进消息流之前，任何位于field-content之间的LWS用单个的SP（空格）
替换。
以什么样的顺序接收具有不同字段名字的报头字段并不重要。但是，一个好的
习惯是先送常规头字段，接着是请求头或应答头的字段，最后是实体头字段。
使用同一个字段名的多个报头字段可能会同时出现在一个消息中，条件是，当
且仅当那个字段的完整字段值被定义成了逗号分割的列表(例如语法为：#(values))。
这就一定能在没有改变消息语义的情况下把多个报头字段组合成一个"域名:域值"对，
方法就是把后续的字段连到前一个的尾部，中间用逗号隔开。这些接收报头字段的顺
序对解析组合字段值是很重要的，因此在一个消息在向前推送的过程中，代理绝对不
能改变这些字段值的顺序。
4.3 消息体
HTTP消息的消息体（译注：消息不一定有消息体，如果有的话）用用来传输由
请求和应答相关的实体。只有当传使用了传输编码的时候，消息体和实体主体才是
不同的，传输编码会在Transfer-Encoding报头字段标明(14.41节)。
message-body = entity-body
|
Transfer-Encoding字段必须用来指定应用程序为了保证消息安全和正确传输的
编码方式。Transfer-Encoding（传输编码）是一种消息的属性而不是实体，因此在
请求/应答链上它可能被任何应用程序加上或去掉。（译注：一个中继连接的两端自
己协商编码，与其他的传输部分无关）(事实上， 3.6节对什么时候使用某种编码做
了限制。）
[页码32]
------------------------------------------------------------------------
对于请求和应答，什么时候消息中允许有消息体的规则是不一样的。
请求中是否有消息体是在报头的Content-Length或Transfer-Encoding字段中标
示的。如果请求方式的规范不允许请求中加入实体则请求中绝对不能包括消息体。
服务器应该读取并处理任何请求中的消息体；如果请求方法没有关于实体的语义定义，
那么在处理这个请求时必须忽略消息体。
对于应答消息，是否其中包括消息体依赖于请求的方法和应答的状态码(6.1.1节)。
所有HEAD请求方法的应答都不能包括消息体，即便是实体头字段的出现让人觉得应
该有（消息体）。所有1XX(信息的)，204(无内容的)，和304(没有修改的)的应答都
绝对不能包括消息体。其他的所有应答都应该包括消息体，即便它可能长度为零。
4.4 消息的长度
一条消息的transfer-length（传输长度）是消息体在消息中的长度，也就是说，
当被传输编码处理以后的长度。当一条消息包含消息体，实体的传输长度由以下几
条决定(以先后顺序):
1.任何绝对不能包含信息体的应答消息中（如1xx，204，304应答和任何对HEAD
请求的回应），总是在报头字段后面的首行以空行（译注：CRLF）的方式结束，而
不管实体头是否出现了。
2.如果Transfer-Encoding（14.41节）报头字段出现了，而且值不是"identity"，
那么传输长度就可以通过使用"chunked"编码后来确定，除非消息由于连接关闭而中
断了。
3.如果Content-Length报头字段(14.13节)出现，那么它的字节记数（十进制值）
将出现在entity-length和transfer-length字段中。但是，如果这两个长度不一致，
Content-Length字段就绝对不可以被发送(例如：如果Transfer-Encoding出现了）。
如果接收一个消息，里面同时有Transfer-Encoding和Content-Length字段，那么后
面的一条必须忽略。
[页码33]
------------------------------------------------------------------------
4.如果消息使用了媒体类型"multipart/byteranges"(多部份/位范围)，并且
ransfer-length（传输长度）字段没有另外指定，那么这个媒体类型就自限定了传
输长度。除非发送方知道接收者能处理这种媒体类型，否则绝对不可以使用；请求
中出现了由HTTP1.1客户在Range（范围）报头中指定的“byteranges”（字节范围），
意味着客户可以解析"multipart/byteranges"应答。
如果1.0代理不能理解"multipart/byteranges"(多部份/位范围)，范围报头字
段也可能会被向前传送；这样的话，服务器必须采用本节第1，3或5条定义的方式界
定信息体。
5.当服务器正在关闭连接。（关闭连接不能用来说明请求体的结束，因为它将
致使服务器没有可能再送回应答。）
为了与HTTP/1.0应用程序兼容，包含消息体的HTTP/1.1请求必须也包括一个有
效“Content-Length”（内容长度）报头字段，除非知道服务器兼容HTTP/1.1。如
果一个请求包含了消息体却没有给出内容长度，如果服务器不能判断消息长度的话，
将会应答400(错误的请求)，或者如果它坚持想要收到一个有效内容的长度应答411
(要求长度)。
所有的HTTP/1.1应用程序必须接受"chunked"传输编码(3.6节)，因此当消息的
长度不能事先确定的时候，允许使用这种机制来处理消息。
消息绝对不能同时包括Content-Length（内容长度）报头字段和不可识别的
transfer-coding（传输编码）。如果消息确实包括了一个不可识别的传输编码字段，
必须忽略Content-Length（内容长度）字段。
当一个Content-Length（内容长度）在消息体允许的地方给出时，这个字段的
值必须和消息体中字节数一致。当接受或者发现一个无效的长度时，HTTP/1.1用户
代理必须通告用户。
4.5 常规报头字段
有一些报头字段在一般的请求和应答消息中都适用，但是不适用于传输中的实
体。这些报头字段只应用于那些发送的消息。
[页码34]
------------------------------------------------------------------------
general-header = Cache-Control ; 14.9
| Connection ; 14.10
| Date ; 14.18节
| Pragma ; 14.32节
| Trailer ; 14.40节
| Transfer-Encoding ; 14.41节
| Upgrade ; 14.42节
| Via ; 14.45节
| Warning ; 14.46节
常规报头字段名字的扩展必须和协议版本的变化相结合。然而，当出现了新的
或实验性质的报头字段，如果信息传输中所有参与者都把它们看做常规报头字段的
话，也可以为它赋予常规报头字段的语义。未被承认的头一般被当做实体报头字段
对待。
5 请求
从客户机到服务器的请求，其首行包括：应用于资源的方法，资源的标识，以
及协议的版本号
Request = Request-Line ; 5.1节
*(( general-header ; 4.5节
| request-header ; 5.3节
| entity-header ) CRLF) ; 7.1节
CRLF
[ message-body ] ; 4.3节
5.1 请求行
请求行的开头是方法标识，接下来是请求URL和协议版本号，以回车换行结束。
各部分之间用空格符(SP)分隔，除了最后的CRLF（回车换行）外，不允许有回车
(CR)和换行(LF)。
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
[页码35]
------------------------------------------------------------------------
5.1.1方法
方法标记指的是在请求URI对指定资源所使用的方法，方法名是大小写敏感的。
Method = "OPTIONS" ;9.2节
| "GET" ;9.3节
| "HEAD" ;9.4节
|"POST" ;9.5节
|"PUT" ;9.6节
|"DELETE" ;9.7节
|"TRACE" ;9.8节
|"CONNECT" ;9.9节
| extension-method
extension-method = token
资源允许的方法列表能由"Allow"（允许）报头字段说明(14.7节)。因为被允许
方法组可以动态改变，所以返回的应答码总是通知客户机当前方法是否被允许。如果
原服务器知道一个方法，但该方法不允许应用于请求的资源，原服务器应当返回状态
码405(方法不允许)。如果方法在原服务器中无法识别或者没有实现，原服务器应当
返回状态码501(没有实现）。所有的普通的服务器都必须支持GET（获取）和HEAD（报
头）方法。其他的方法都是可选的，然而，假若以上的方法实现了，他们就必须按照
第九章里所说明的语义来实现。
5.1.2 请求URL
请求URL是一种全球统一的应用于资源请求的资源标识符（3.2 节）。
Request-URI = "*" | absoluteURI | abs_path | authority
请求URI的四个选项是依赖于请求的特性的。星号"*"表示请求不是应用于某个
特别资源的，而是服务器本身，只有当所用的方法不是必须应用于某个资源时候，
（"*"）才是允许的。举例如下
OPTIONS * HTTP/1.1
对服务代理发出请求时，绝对URI地址是不可缺少的。请求服务代理转发请求，
或者利用有效期内的缓存进行服务，返回应答。注意：代理服务器可能会把请求转
发给另一个服务代理或直接转发给绝对URI地址指定的服务器。为了避免请求循环，
代理服务器必须能识别所有的服务器名字，包括任何别名，本地变异名，数字形式
的IP地址。请求行一般是这样的：
[页码36]
------------------------------------------------------------------------
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
为了在未来的HTTP版本的所有请求中转换绝对URL地址，所有基于HTTP/1.1的
服务器必须能接受绝对URL地址形式的请求，即便基于HTTP/1.1的客户机将只把这
样的请求发给服务代理。
授权形式只是在CONNECT（连接）方法中用到（9.9节）。
请求URI的最一般形式是用来标识原服务器或网关上的资源。这种情况下，绝对
URL路径必须作为请求URL传送（看3.2.1节，绝对路径），表示网络位置的部分必须
放在HOST报头字段传输。例如，希望一个客户想得到原服务器的资源，就要在
"www.w3.org"主机的80端口建立TCP连接发送以下行：
GET /pub/WWW/TheProject.html HTTP/1.1
Host:www.w3.org
接下来是请求的其他部分，注意：绝对路径不能是空的；假如没有初始的URI，
必须给出"/"（服务器根目录）。
请求URL传输时候使用的格式在3.2.1节里有说明。如果用"%HEX HEX" [42]模
式编码，为了正确的解析请求，原服务器必须解码。对于无效的请求，服务器必须
给予一个带有合适状态码的应答。
当透明服务代理转发收到的请求URL给下一台网内的服务器时，绝对不可以重写
"绝对路径"部分，上面提到的用"/"代替空绝对地址情况除外。
注：当原服务器不恰当的使用"非保留URL字符"作保留使用时，"禁止重写"规则
防止代理服务器更改请求的含义。实现程序员应该知道，HTTP/1.1以前版本的服务
代理会改写请求URL。
[页码37]
------------------------------------------------------------------------
5.2"请求"定义的资源
一个因特网请求所标识的那个资源由请求URL和Host报头字段所决定。
在判定HTTP/1.1协议中标识的请求资源时，如果服务器不容许请求中的资源和
HOST字段不一样，那么原服务器就会忽略Host字段值。（查看19.6.1.1节了解HTTP
/1.1中 Host字段的其他要求）。
根据请求的主机区分资源的服务器，(有时指虚拟主机或无主机名情况)，必须
用以下的规则判定"HTTP/1.1请求"中所请求的资源：
1.如果请求URI是绝对地址，主机是请求URI的一部分。任何Host报头字段都应
当被忽略。
2.假如请求URI不是绝对地址，且请求包括一个Host报头字段，则主机由该字段
的值所决定。
3.假如根据规定1或规定2得到主机是无效的，则应答当是一个400（错误请求）
的出错信息。
为了找出真正被请求的资源，对于一个缺乏主机标识字段的HTTP/1.0请求，接
收者可以尝试使用试探的方法。（例如：对于特定的主机，检测URI中某些唯一性的
东西）。
5.3"请求"报头字段
“请求”的报头字段允许客户传递关于请求的附加信息给服务器，还可以是有关
客户自己的信息。这些字段作为请求修饰成分，和程序语言中方法调用的参数有差不
多的含义。
[页码38]
------------------------------------------------------------------------
请求报头 ＝ 接收(Accept) ;14.1节
|接收Charset (Accept-Charset) ;14.2节
|接收编码(Accept-Encoding) ;14.3节
|接收语言(Accept-Language) ;14.4节
|认证(Authorization） ;14.8节
|期望(Expect) ;14.20节
|源(From) ;14.22节
|主机(Host) ;14.23节
|假如匹配(If-Match) ;14.24节
|假如修改(If-Modified-Since) ;14.25节
|假如不匹(If-None-Match) ;14.26节
|假如归类(If-Range) ;14.27节
|假如不修改(If-Unmodified-Since ) ;14.28节
|最大转发量(Max-Forwards ;14.31节
|代理认证( Proxy-Authorization) ;14.34节
|范围(Range) ;14.35节
|提交者(Referer) ;14.36节
|TE ;14.39节
|用户代理(User-Agent) ;14.43节
随着协议版本的变化，“请求”报头字段的名字可以可靠的扩展。然而，如果
通信中的所有参与方都能识别新的或实验性的报头字段，那么这些字段就可以被赋
予报头字段的语义，不可识别的字段将被作为实体头来对待。
6 应答
接收和解析一个请求信息后，服务器发出一个HTTP应答消息。
Response = Status-Line ; 6.1节
*(( general-header ; 4.5节
| response-header ; 6.2节
| entity-header ) CRLF) ; 7.1节
CRLF
[ message-body ] ; 7.2节
6.1 状态行
应答信息的第一行是状态行，由协议版本、数字状态码和相关的文本说明组成。
各部分间用空格符隔开，除了最后的CRLF回车换行外，中间不允许有回车或者换行。
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
6.1.1状态码与注解
状态码是试图理解和满足请求的一个三位数，这些码在第十章有完整定义。注
解短语是为了给出关于状态码的文本描述。状态码用于自动控制而注解短语是面向
用户的。客户机不需要检查或显示注解短语。
[页码39]
------------------------------------------------------------------------
状态码的第一位数字定义应答类型。后两位数字没有任何用来分类的任务。第
一位数字有五种值：
-1xx: 报告的 - 接收到请求，继续处理
-2xx 成功 - 操作成功的收到，理解和接受
-3xx 重定向 - 为了完成请求，必须采取进一步措施。
-4xx 客户端出错 - 请求的语法有错误或者不能完全被满足。
-5xx 服务器出错 - 服务器无法完成明显有效的请求。
为HTTP/1.1定义的状态码单个的值，和一个相应的一系列注解的例子介绍如下。
这儿列出的注解短语只是建议――它们可以被等价物取代而不会影响协议。
Status-Code ＝
"100" ; 10.1.1节: 继续
|"101" ; 10.1.2节: 转换协议
|"200" ; 10.2.1节: OK
|"201" ; 10.2.2节: 创建
|"202" ; 10.2.3节: 接受
|"203" ; 10.2.4节: 非权威信息
|"204" ; 10.2.5节: 无内容
|"205" ; 10.2.6节: 重置内容
|"206" ; 10.2.7节: 局部内容
|"300" ; 10.3.1节: 多样选择
|"301" ; 10.3.2节: 永久移动
|"302" ; 10.3.3节: 创建
|"303" ; 10.3.4节: 观察别的部分
|"304" ; 10.3.5节: 只读
|"305" ; 10.3.6节: 用户代理
|"307" ; 10.3.8节 临时重发
|"400" ; 10.4.1节: 坏请求
|"401" ; 10.4.2节: 未授权的
|"402" ; 10.4.3节: 必要的支付
|"403" ; 10.4.4节: 禁用
|"404" ; 10.4.5节: 没找到
|"405" ; 10.4.6节: 不允许的方式
|"406" ; 10.4.7节: 不接受
