1、超文本传输协议-HTTP/1.1 说明 本文档规定了互联网社区的标准组协议，并需要讨论和建议以便更加完善。请参考 “互联网官方协议标准” （STD 1）来了解本协议的标准化状态。本协议不限流传发布。版权声明 Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (2007). All Rights Reserved. 摘要 超文本传输协议（HTTP）是一种为分布式，合作式，多媒体信息系统服务，面向应用层的协议。它是一种通用的，不分状态（stateless)的协议，除了诸如名称服务和分布对象管理系统之
2、类的超文本用途外，还可以通过扩展它的请求方式，错误代码和报头47来完成许多任务。HTTP 的一个特点是数据表示方式的典型性和可协商性允许独立于传输数据而建立系统。 HTTP 在1990 年 WWW 全球信息刚刚起步的时候就得到了应用。本说明书详细阐述了 HTTP/1.1 协议，是 RFC 2068 的修订版 33。 目录（略） 1 引论 1.1 目的 超文本传输协议（HTTP）是一种为分布式，合作式，多媒体信息系统服务，面向应用层的协议。在 1990 年 WWW 全球信息刚刚起步的时候 HTTP 就得到了应用。HTTP 的第一个版本叫做HTTP/0.9,是一种为互联网原始数据传输服务的简单协议
3、。由 RFC 19456定义的 HTTP/1.0 进一步完善了这个协议。它允许消息以类似 MIME 的格式传送，包括有关数据传输的维护信息和关于请求/应答的句法修正。但是，HTTP/1.0 没有充分考虑到分层代理，高速缓存的作用以及对稳定连接和虚拟主机的需求。并且随着不完善的进程应用的激增，HTTP/1.0 迫切需要一个新的版本,以便使两个通信应用程序能够确定彼此的真实性能。 这里规定的协议叫做“HTTP/1.1“.这个协议与 HTTP/1.0 相比，要求更为严格，以确保各项功能得到可靠实现。 实际的信息系统除了简单的检索外，要求更多的功能性（functionality)，包括查找(searc
4、h)，前端更新(front-end update)和注解(annotation)。HTTP 允许可扩充的方法集和报头集以指示请求的目的47。它是建立在统一资源标识符（URI）3提供的地址（URL）4和名字（URN）上20，以指出方法应用于哪个资源的。消息以类似于一种叫做多用途网络邮件扩展（MIME）7 的互联网邮件的格式传送。 HTTP 也是用于用户代理之间及代理/网关到其他网络系统的通用通信协议，这样的网络系统可能由 SMTP16,NNTP13,FTP18,Gopher2和 WAIS10协议支持。这样，HTTP 允许不同的应用程序对资源进行基本的超媒体访问。1.2 要求 本文的关键词“MUS
5、T“, “MUST NOT“, “REQUIRED“, “SHALL“,“SHALL NOT“,“SHOULD“, “SHOULD NOT“, “RECOMMENDED“, “MAY“, 和 “OPTIONAL“将由 RFC 211934解释。 一项进程如果不能满足协议提供的一个或多个 MUST 或 REQUIRED 等级的要求，是不符合要求的。一项进程如果满足所有 MUST 或 REQUIRED 等级以及所有 SHOULD 等级的要求，则被称为“绝对符合” （unconditionally compliant）的；若满足所有 MUST 等级的要求但不能满足所有SHOULD 等级的要求则被称为
6、“部分符合” （conditionally compliant）的。 1.3 术语 本说明用到了若干术语，以表示 HTTP通信中各参与者和对象扮演的不同角色。 连接（Connection）为通信而在两个程序间建立的传输层虚拟电路。 消息(Message) HTTP通信中的基本单元。它由一个结构化的八比特字节序列组成，与第4 章定义的句法相匹配，并通过连接得到传送。 请求(Request) 一种 HTTP 请求消息，参看第 5 章的定义。 应答(Response) 一种HTTP 应答消息，参看第 6 章的定义。 资源(Resource) 一种网络数据对象或服务，可以用第 3.2 节定义的 URI
7、 描述。资源可以以多种表现方式（例如多种语言，数据格式，大小和解决方案）或其他不同的途径获得。 实体(Entity) 作为请求或应答的有效负荷而传输的信息.一个实体包含报头形式的维护信息和消息体形式的内容,由第 7 节详述. 表示方法(Representation) 一个应答包含的实体是由内容协商决定的,如第 12 章所述.一个特定的应答状态所对应的表示方法可能有多个. 内容协商(Content Negotiation) 为请求服务时选择适当表示方法的机制（mechanism),如第 12 节所述.任何应答里实体的表示方法都是可协商的(包括出错应答). 变量（Variant) 在任何给定时刻,
8、与一个资源对应的表示方法可以有一个或更多.每个表示方法称作一个变量.使用变量这个术语并不必然意味着资源是由内容协商决定的. 客户机（Client）为发送请求建立连接的程序. 用户代理(User agent) 初始化请求的客户端程序.常见的如浏览器,编辑器,蜘蛛(网络穿越机器人),或其他的终端用户工具. 服务器(Server) 同意连接以便通过发回应答为请求提供服务的应用程序.任何给定的程序都有可以既做客户端又做服务器;我们使用这些术语仅指特定连接中程序完成的任务,而不是指通常意义上程序的性能.同样,任何服务器都可以基于每个请求的性质扮演原服务器,代理,网管,或者隧道等诸角色之一。 原服务器（O
9、rigin server) 给定的资源驻留或创建的地方. 代理服务器（ Proxy）一个既做服务器又做客户端的中介程序.,其用途是代表其他客户发送请求.请求在内部得到服务,或者经过一定的翻译转至其他服务器.一个代理服务器必须能同时履行本说明中客户端和服务器要求.“透明代理”（transparent proxy）是一种除了必需的验证和鉴定外不修改请求或相应的代理.“非透明代理” （non-transparent proxy）是一种修改请求或应答以便为用户代理提供附加服务的代理,附加服务包括类注释服务,媒体类型转换,协议简化,或者匿名滤除等.除非经明确指出,HTTP 代理要求对两种代理都适用. 网
10、关（gateway）为其他服务器充当中介的服务器.与代理服务器不同,网关接收请求,仿佛它就是被请求资源所在的原服务器;提出请求的客户可能觉察不到它正在同网关通信. 一个在两个连接之间充当盲目中继（blind relay)的中间程序.一旦有效,隧道便不再被认为是 HTTP 通信的用户,虽然隧道可能已经被 HTTP 请求初始化了.当两端的中继连接都关闭的时候,隧道不再存在. 高速缓存（Cache）一个程序应答信息的本地存储和控制此信息存储、检索和删除的子系统,一个高速缓冲存储器存储应答为的是减少对将来同样请求的应答时间和网络带宽消耗,任一客户或服务器都可能包含一个高速缓存,但高速缓存不能应用于一个
11、充当隧道的服务器. 可缓存（Cacheable） 如果一个高速缓存允许存储应答信息的一份拷贝运用于应答后继请求的拷贝,一个应答就是可缓存的.用来确定 HTTP 应答的缓存能力（cacheability）的规则在 13 节中有定义.即使一个资源是可缓存的,也可能对一个高速缓存能否将缓存拷贝用于某特定请求存在附加的约束. 直接（first-hand） 如果一个应答直接到来并且没有缘于原服务器,或若干代理服务器的不必要的延时,那么这个应答就是直接的.如果它的有效性已经被原服务器直接认证,那么这个应答也同样是第一手的. 明确终止时间（explicit expiration time） 原服务器预算一个
12、实体在无需进一步确认的情况下不再被高速缓存返回的时间. 探索终止时间（heuristic expiration time） 当没有外在的终止时间可利用时, 由高速缓存所指定的终止时间. 年龄（Age） 一个应答的年龄是从它被发送,或被原服务器成功确认到现在的时间. 保鲜寿命（Freshness lifetime）一个应答生成和过期之间的时间长度. 保鲜（Fresh） 如果一个应答的年龄还没有超过保鲜寿命,它就是保鲜的. 陈旧（Stale） 一个应答的年龄已经超过了它的保鲜寿命,就是陈旧的. 语义透明（semantically transparent）当它的使用除了改善性能外既未影响请求客户机也
13、未影响原服务器时, 高速缓存对于某特定的应答就是工作于语义透明方式了.当高速缓存语义透明时,客户恰好收到与原服务器直接处理请求后得到的应答（除了逐段转接的报头部分）完全相同的应答。 有效性判别器（Validator） 一个用来查找一个高速缓存记录是否是一个实体的等效拷贝的协议元素(例如,一个实体标记（entity tag）或最终更改时间（Last-Modified time). 上游/下游（upstream/downstream） 上游和下游描述了消息的流动:所有消息都从上游流到下游. 向内/向外（inbound/outbound）向内和向外指的是消息的请求和应答路径:“向内“即“移向原服务器
14、“,“向外“即“移向用户代理“. Copyright (2007). All Rights Reserved. 1。4 总体操作 HTTP 协议是一种请求/应答协议。 与主机建立连接后，客户以请求方法，URI 和协议版本的形式向服务器发送请求，继以类 MIME 信息，其中包括请求修改，客户信息和可能的正文内容。服务器用包括消息协议版本和成功或错误代码的状态进行应答，继以包括服务器信息，实体维护信息和可能的实体内容的类 MIME 消息。HTTP 和 MIME之间的关系如附录 19.4 节所阐述。 大部分的 HTTP 通信由用户代理引发，由应用到一些原服务器上资源的请求构成。最简单的情形，可以经
15、用户代理（UA）和原服务器（O）之间的单一连接（v）完成。请求链-用户代理(UA)-单一连接（v)-原服务器（O） UA-v-A-v-B-v-C-v-O UA-v-A-v-B-C-O “）,跟等于号“=“后面的定义是分离的。仅当连续线的空格用来表示一条长于一行的规则时空白才是重要的。某些基本规则使用大写字母，如SP，LWS，HT，CRLF，DIGIT，ALPHA，等等。无论何时，只要它们的存在有利于识别规则名字，就可以在定义的范围内使用角括号。 “文字” 文字原文使用引号。除特殊情况，原文对外界不敏感。 规则 1 | 规则 2 由竖线(“|“）分开的元素是可选的，例如，“yes | no“表示
16、 yes 或 no 都是可接受的。 （规则 1 规则 2）围在括号里的多个元素视作一个元素。这样“(elem (foo | bar) elem)”允许标记序列“elem foo elem”和 elem bar elem”。 *规则前面的字符“*“表示重复。完整的形式是“*元素“,表示元素至少出现次，至多出现次。默认值是 0 和无穷大，所以“*(元素)“允许任何数值，包括零；“1*元素“至少需要一次；“1*2element“允许一次或两次。 规则 方括号里是任选元素；“foo bar“相当于“*1(foo bar)“. N 规则特殊的重复：“(元素)”相当于“*(元素)” ； 也就是说，(元素)
17、正好出现了次。这样 2DIGIT 是一个两位数字，3ALPHA 是一个由三个字符组成的字符串。 #规则类似于“*“,结构“#“是用来定义一系列元素的。完整的形式是“#元素,表示至少个元素，至多个元素，元素之间被一个或多个逗号(“,“)以及可选的线性白色空间(LWS)隔开了。这就使得列表的一般形式变得非常容易；像 ( *LWS element) *( *LWS “,“*LWS element ) 就可以表示为 1#element 无论在哪里使用这个结构，空元素都是元许的，但是不计入元素出现的次数。换句话说， “(元素), , (元素) “是允许的，但是仅仅视为两个元素。因此，在至少需要一个元素的
18、地方，必须存在至少一个非空元素。默认值是 0 和无穷大，这样， “#element”允许任何数字，包括零；“1#element”至少需要 1 个元素；“1#2element”允许 1 个或 2 个元素。 ；注释用分号引导的注释，从规则正文的右边一段距离开始直到行尾。这是做注释的简单方法，注释与说明是同样有用的。 隐含 *LWS 本说明书所描述的语法是基于字的。除非特别注明，线性空白可出现在任何两个相邻字之间（标记或引用字符串） ，以及相邻字和间隔符之间，并不改变一个域的含义。任何两个标记之间（下面会对“token(标记)“进行定义）必须有至少一个分割符，否则将会被理解为单一标记。 22 基本规
19、则 下面的规则描述了基本的解析结构，贯穿于本说明书的全文。US-ASCII(美国信息交换标准码)字符规定是由 ANSI X3.4-198621定义的。 OCTET = CHAR = UPALPHA = LOALPHA = ALPHA = UPALPHA | LOALPHA DIGIT = CTL = CR = LF = SP = HT = = HTTP/1.1 将 CR LF 的顺序定义为任何协议元素的行尾标志，除了报文以外（宽松应用见附录 19.3）.报文内部的行尾标志是由它的关联媒体类型定义的，如 3.7 节所述。 CRLF = CR LF 如果延长线由空格或水平制表开始，HTTP/1.1
20、 的报头域值可以折叠到到复合线上。所有的线性空白，包括折叠，具有同 SP 一样的语义。接收者在解释域值或将消息转送到下游时可以用单个 SP 替代任何线性空白。 LWS = CRLF 1*( SP | HT ) 文本规则仅仅适用于描述域的内容和不会被消息语法分析程序解释的值。*TEST 的字可以包含 ISO-8859-122里的字符，也可以包含字符规定里的字符14。 TEXT = 一个CRLF 仅仅在作为报头域延续的一部分时才在 TEXT 定义里允许使用。十六进制数字字符用在数个协议元素里。 HEX = “A“ | “B“ | “C“ | “D“ | “E“ | “F“ | “a“ | “b“
21、| “c“ | “d“ | “e“ | “f“ | DIGIT 许多 HTTP/1.1 的报头域值是由 LWS 或特殊字符分隔的字构成的。这些特殊字符必须包含在引用字符串里，方可用在参数值（如3.6 节定义）里。 token （标记） = 1* separators（分割符） = “(“ | “)“ | “ | “ | “,“ | “;“ | “:“ | “ | | “/“ | “ | “ | “?“ | “=“ | “ | “ | SP | HT 用圆括号括起来的注释可以包含在一些 HTTP 报头域里。只有作为域值定义的一部分时注释才是允许的。在其他域里，圆括号视作域值的一部分。 comme
22、nt （注释）= “(“ *( ctext | quoted-pair | comment ) “)“ ctext = 一个文本字符若在双引号里，则当作一个字。 quoted-string = ( *(qdtext | quoted-pair ) ) qdtext = 以外的任意 TEXT 反斜线(“)可以用作单一字符引用结构，但仅在引用字符串或注释里。 quoted-pair = “ CHAR 3 协议参数 3.1 HTTP 版本 Copyright (2007). All Rights Reserved. HTTP 使用“.“的编号方案表示协议版本。协议的版本方针是希望允许发送者表示消息
23、的格式和性能以便理解更深一层的 HTTP 通信，而不仅仅是当前通信获得的特征。消息构件的增加不影响通信动作，或仅仅增加了扩展域值，版本号并没有因此变化。协议的改变增加了一些特征，没有改变一般的消息解析规则，但是增加了消息的语义或者暗含了发送者新增的性能，这时数字便要增大。当协议的消息格式改变时，数字增大。 HTTP 消息的版本在消息的第一行 HTTP-版本域里表示。 HTTP-Version = “HTTP“ “/“ 1*DIGIT “.“ 1*DIGIT 注意主要和次要数字必须看作是两个分离的整数，二者都可以增加到比单位数还大。这样，HTTP/2.4 的版本比 HTTP/2.3 低，依次 H
24、TTP/2.3 的版本比 HTTP/12.3 低。首位的零必定被接收者忽视，一定不要发送。 一个发送包含 HTTP 版本“HTTP/1.1“的请求或应答消息的应用，必须至少有条件的服从本说明书。至少有条件服从本说明书的应用应该在消息里使用“HTTP/1.1“的 HTTP-版本，任何与 HTTP/1.0 不兼容的消息则必须这样做。关于何时发送特殊的 HTTP-版本值，更多资料请参看 RFC 214536. 一项应用的 HTTP 版本是应用至少有条件服从的最高 HTTP 版本. 代理和网关转送的消息的协议版本与应用版本不同时，需要小心。既然协议版本表示发送者的协议性能，代理/网关一定不能发送标示版
25、本高于它本身的实际版本的消息。如果收到更高版本的请求，代理/网关必须降低请求的版本，或者发出出错应答，或者切换到隧道动作。 由于自 RFC 206833发布后发现的HTTP/1.0 代理协同工作问题，高速缓存代理必须，网关可以，隧道必须不将请求提升到它们支持的最高版本。代理/网关的应答的主要版本号必须同请求相同。 注：HTTP 版本的转换可能会包含相关版本必需或禁止的头域修改。 3.2 统一资源标识符（ URI） URIs 的许多名字已为人所知：WWW 地址,通用文件标识符，通用资源标识符3，以及最后统一资源定位器(URL)4和统一资源名称(URN)20的结合。只要与 HTTP 相关，统一资源
26、定位器只是格式化的字符串，它通过名称，地址，或任何别的特征确定了资源的位置。 3.2.1 一般语法 根据使用时的上下文，HTTP 里的 URI 可以表示成绝对形式或基于已知的 URI 的相对形式。两种形式的区别是根据这样的事实：绝对 URI 总是以一个摘要名字作为开头，其后是一个冒号。关于URL 更详尽的信息请参看“统一资源标识符(URI):一般语法和语义“,RFC 2396 42(代替了 RFCs 1738 4和 RFC 1808 11).本说明书采用那份说明书里关于“URI-索引“,“绝对 URI“,“相对 URI“,“端口“,“主机“,“绝对路径“和“权力“的定义. HTTP 协议不对
27、URI 的长度作事先的限制.服务器必须能够处理它们服务的任何资源的 URI,并且应该能够处理无限长度的 URI,如果它们提供可以产生这种 URI 的基于 GET 的形式. 注:服务器在依赖长于 255 字节的 URI 时应谨慎,因为一些旧的客户或代理实现可能不支持这些长度. 3.2.2 http URL http 方案通过 HTTP 协议定出网络资源的位置.本节定义了这种方案-http URL 特殊的语法和语义 . http_URL = “http:“ “/“ host “:“ port abs_path “?“ query 如果端口为空或未给出,就假定为 80.语义即:已识别的资源放在服务器
28、上,在那台主机的那个端口上监听 TCP 连接,对资源的请求的 URI 为绝对路径(5.1.2节). 无论什么可能的时候,URL 里使用 IP 地址都是应该避免的(参看 RFC 1900 24).如果绝对地址没有出现在 URL 里,它用作对资源的请求的 URI 时必须作为“/“给出.如果代理收到一个不是充分资格域名的主机名,一定不能改变主机名. 3.2.3 URI 比较 当比较两个URI 是否匹配时,客户应该对整个 URI 进行区分大小写,以八字节为单元的比较.以下情况例外: -一个为空或未给定的端口等同于那个URI 索引里的默认端口; -主机名的比较必须是不区分大小写的; -方案名的比较必须是
29、不区分大小写的; -一个空绝对路径等同于绝对路径“/“. Characters other than those in the “reserved“ and “unsafe“ sets are equivalent to their “%“ HEX HEX“ encoding. 除了“保留“或“危险“集里的字符(参见 RFC 2396 42) ,字符等同于它们的“%“ HEX HEX“编码. 例如,以下三个 URI 是等同的: http:/:80/smith/home.html http:/ABC.com/smith/home.html http:/ABC.com:/smith/home.ht
30、ml 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 Cs asctime() format 第一种格式是作为 Internet 标准提出来的,它表示一个由 RFC 1123 8(RFC 8229的升级版本)定义的固定长
31、度的子集.第二种格式使用比较普遍,但是基于废弃的 RFC 850 12,需要(应该)用四位数表示年份.对日期值进行语法分析的 HTTP/1.1 客户和服务器必须接受所有三种格式(为了同 HTTP/1.0 兼容),虽然它们必须只产生 RFC 1123 格式以在头域里表示 HTTP 日期值. 注:鼓励日期值的接收者在接受可能由非 HTTP 应用发来的日期值时要坚定,这种非 HTTP 应用有时是通过代理/网关到 SMTP 或 NNTP 检索或张贴消息. 所有的 HTTP 日期/时间印记都必须毫无例外的以格林威治平均时间(GMT)表示.为了 HTTP,GMT 完全等同于 UTC(协调世界时间).这在前
32、两种形式里用三个字母的时区缩写-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 4D
33、IGIT 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“ | “We
34、d“ | “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 De
35、lta 秒 一些 HTTP 头域收到消息后,允许以十进制整数秒表示的时间值. delta-seconds = 1*DIGIT 3.4 字符集 HTTP 使用的关于术语“字符集“的定义和 MIME 中所描述的一样. 本文档中的术语“字符集“指一种用一个或更多表格将一个八字节序列转换成一个字符序列的方法.注意另一方向的无条件转换是不需要的,在这种转换里,并不是所有的字符都能在一个给定字符集里得到,并且字符集可能提供多个八进制序列表示一个特定字符.这个定义将允许各种字符编码方式,从简单的单表格映射如 US-ASCII 到复杂的表格交换方法如 ISO-2022 的技术里所使用的.然而,与 MIME 字
36、符集名字相关联的定义必须充分说明从八字节变换到字符所实现的映射.特别的,使用外部轮廓信息来决定精确映射是不允许的. 注:这里使用的术语“字符集“更一般的被称作一种“字符编码“.不过既然 HTTP 和 MIME 使用同样的注册表,共用术语是很重要的. HTTP 字符集用不区分大小写的标记表示.完全标记集合由 IANA 字符集注册表19定义. charset = token 尽管HTTP 允许用任意标记作为字符集的值,任何在 IANA 字符集注册表里有预先确定值的标记必须表示该注册表定义的字符集.对那些 IANA定义的字符集,应用应该限制使用字符集. 实现者应该注意 IETF 字符集的要求3841
37、. 3.4.1 失踪字符集 一些 HTTP/1.0 软件将没有字符集参数的内容类型头错误的理解为“接收者应该猜猜.“若发送者希望避免这种情况,可以包含一个字符集参数,即使字符集是 ISO-8859-1;当知道不会使接收者混淆时,也应该这样做. 不幸的是,一些旧的 HTTP/1.0 不能适当处理详细的字符集参数.HTTP/1.1 接收者必须重视发送者提供的字符集标注;当最初显示文档时，那些提供“猜“字符集服务的用户代理必须使用内容类型域中的字符集，如果它们支持那个字符集，而不是接收者的首选项。参看 3.7.1 节。 3.5 内容编码 内容编码值表示一种已经或可以应用于实体的编码变换。内容编码主要
38、用来允许文档压缩，换句话说，有效的变换而不损失它的基本媒体类型的特性，也不丢失信息。经常地，实体以编码形式储存,直接传送,只能由接收者译码. content-coding = token 所有内容编码值都是不区分大小写的.HTTP/1.1 在接收译码(14.3 节)和内容译码(14.11 节)的头域里使用内容编码值.尽管该值描述了内容编码,更重要的是它指出需要什么编码机制来除去编码. 互联网赋值机构(IANA)充当内容编码值标记的注册处.最初,注册表包含下列标记: gzip（压缩程序） 一种由文件压缩程序“gzip“(GNU zip)-如 RFC 1952 所描述-生成的编码格式.这种格式是一
39、种 32 位 CRC Lempel-Ziv 编码(LZ77). 译者注CRC:循环冗余校验 compress（压缩）由通用 UNIX 文件压缩程序“compress“生成的编码格式.这种格式是一种具有可适应性的 Lempel-Ziv-Welch 编码. 对未来的编码来说,用程序名识别编码格式是不可取,令人气馁的.在这里他们的用处是作为历史实践的代表而不是好的方案.为了同以前的HTTP 实现相兼容,应用应该将“x-gzip“和“x-compress“分别等同于“gzip“和“compress“. deflate（缩小） RFC 1950 31定义的“zlib“格式与 RFC 1951 29描述的
40、“deflate“压缩机制的组合. Identity（标识） 缺省(标识)编码;无论如何,不进行转化的应用.这种内容译码仅被用于接受译码报头,并且不能被用在内容编码报头. 新的内容译码值的标记应该注册;为了允许客户和服务器间的互用性,内容译码运算的规范需要实现一个可被公开利用并能独立实现的新值,并且与这节中内容译码定义的目的相一致. 3.6 传输编码 传输编码值被用来表示一个已经,能够,或可能需要应用于一个实体的编码转化,为的是能够确保通过网络安全传输.这不同于内容译码,传输译码是消息的特性而不是原始实体的特性. transfer-coding = “chunked“ | transfer-e
41、xtension transfer-extension = token *( “;“ parameter ) 参数采用属性/值对的形式. 参数 = 属性 “=“ 值 属性 = 标记 值 = 标记 | 引用-串（quoted-string） 所有传输译码值是不直观的.HTTP/1.1 在 TE 头域(14.39 节)和传输译码头域(14.41 节)运用传输译码. 无论何时一个传输译码都被应用于一个消息体,传输译码的设置必须包括“大块“,除非消息被结束连接停止.当“大块“传输译码被应用时,它必须是应用于消息体的最后传输译码.这些规则允许接受从而确定消息的传输长度(4.4 节) 传输译码与 MINE
42、7的内容传输译码值相类似,它被定义能够实现传送服务器超过 7 位的二进制数据的安全传输.不过,安全传输对纯 8 位传输协议有不同的焦点.在 HTTP 中,消息体唯一不安全的特性是确定确切的体的长度的这个难点(7.2.2 节),或在共享传输上加密的要求. 网络分配数字权威(IANA)担任了传输译码值标记注册处的角色.起初,注册包含如下标记:“大块“(3.6.1 节),“身份“(3.6.2 节),“gzip“(3.5 节),“压缩“(3.5 节),和“缩小“(3.5 节). 新的传输译码值标记应和新的内容译码值标记以相同的方式注册(3.5 节). 服务器接收到一个不能理解的传输译码实体时应返回 5
43、01(不实现),并且切断联系.服务器不能向 HTTP/1.0 客户发送传输译码. 3.6.1 成块传输代码（Chunked Transfer Coding） 成块编码更改消息主体,为的是将它以一系列大块的形式传送,每一个连同它自己尺寸的指示器,被一个包含实体头域的可随意选择的 trailer 跟随.这允许有力量的地生产同接受所必需的消息一起转化的内容,从而检验它已经获得全部消息. Chunked-Body = *chunk(大块) 大块-正文 last-chunk(最后-大块) trailer(追踪者) CRLF chunk = chunk-size chunk-extension CRLF
44、大块 = 大块-尺寸 大块 -扩展CRLF chunk-data CRLF 大块-数据 CRLF chunk-size = 1*HEX 大块数据 last-chunk = 1*(“0“) chunk-extension CRLF 最后-大块 = 1*(“0“) 大块-扩展CRLF chunk-extension= *( “;“ chunk-ext-name “=“ chunk-ext-val ) 大块-扩展 大块- 外部-名称 大块-外部-值 chunk-ext-name = token 大块-外部-名称= 标记 chunk-ext-val = token | quoted-string 大块
45、-外部-值 = 标记 | 引用-串 chunk-data = chunk-size(OCTET) 大块-数据 = 大块 -尺寸(八位子节) trailer = *(entity-header CRLF) 追踪者 = * (实体-领先 CRLF) 大块尺寸域是用 16 进制表示大块尺寸的一串数字.成块编码以任一尺寸为 0 的大块结束,后缀以 trailer,以一个空行终止. trailer 允许发送者在消息末尾包含附加的 HTTP 头域.trailer 头域可被应用于简要说明包含 trailer 的头域 (14.40 节) 一个服务器在应答中运用传输译码时不能在任何头域使用 trailer,除非
46、以下至少一条为真: a) 请求包括一个 TE 头域时表明“trailer“在应答的转移译码中是可被接受的,就像 14.39 节中描述的那样;或者 b) 服务器是为了应答的原始服务器,trailer 的域完全由随意的元数据构成,这个接收者可以在不接受这个元数据的情况下使用消息(在一个原始服务器可接受的方式中).另一方面,原始服务器愿意接受 trailer 域可能会在通往客户的通道上被默默放弃的这种可能性. 当消息被一个HTTP/1.1 代理人接受并且 8 转寄至一个 HTTP/1.0 接受器时,这种需求防止了一个互用性的失误.它避免了一个依据协议将使在代理者上安置一个可能无限大的缓冲器成为必要的
47、情形发生. 对一个大块主体进行解码处理的例子已在附录 19.4.6 中作过介绍 所有 HTTP/1.1应用程序必须能接受和解码“大块“传输译码,并且必须忽略它们不理解的大块扩展扩展名. 3.7 媒体类型 为了提供公开的,可扩展的数据输入和规范流通,HTTP 在目录类型(14.17 节)和认可(14.1 节)头域中运用网络媒体类型. 媒体类型 = 类型 “/“ 亚类型*(“;“ 参数 ) 类型 = 标记 亚类型 = 标记 参数可能在属性/值的形式上遵循类型/亚类型.(如 3.6 节定义) 类型,亚类型,和参数属性名称是不直观的.参数值直观与否,取决于参数名称的意义. 线性的白色空间(LWS)不能
48、被用于类型和亚类型之间,也不能用于一种属性及他的值之间.一个参数存在与否对媒体类型的处理有着重要的意义,取决于它在媒体类型注册中的定义. 注意一些旧的 HTTP 应用软件不能识别媒体类型参数.向一个旧的 HTTP 应用软件传送数据时,只有当类型/亚类型精确度需要时,才能实现媒体类型参数. 媒体类型值已经在网络分配数码权威(IANA19)注册.媒体类型的注册程序在 RFC 159017中略述.使用未经注册的媒体类型是不会得心应手的. 3.7.1 规范化和原文缺省 网络媒体类型以语言的语音典型形式注册.一个通过 HTTP 通讯传输的实体必须被以先于传送的适当的规范的形式描绘,除text类形以外,就像下段定义的那样. 当在规范的形式中,text类型的媒体亚类型运用 GRLF 作为全文行的间断.HTTP 放松了这个要求,当一个完整实体被间断完成时,允许全文媒体以简单的 GR 或 LF 独立作为一行的隔断的传输. 在通过 HTTP 承认的原文媒体中,作为一个行的间断的代表,HTTP 应用程序必须接受 CRLF,空的 CR,和空的 LF. 而且,如果原文在一个特性设置中被表现,没有分别用 8 位字节 13 和 10 表示CR 和 LF,就像某种多重字节特性设置,HTTP 允许使用任何被为了表现 CR 和 LF 在行间断中的等同的特性设置所定义的任何 8 位字节次序
