HTTP超文本传输协议-HTTP/1.1中文版(2)

一个请求的消息体是用来传达内容长度或请求传输编码头的传输编码头域的信息.如果请求方式的规范不允许请求中加入实体则一个请求中也必须不能包括消息体.一个服务器必须读和处理任何请求的消息体;如果请求方法没有定义一个实体的表述,则当处理这个请求是必须忽略消息体.

对于应答消息,一个消息是否包括消息体依赖于请求的方法和应答的状态代码(6.1.1节).对于所有头请求方法的应答都不能包括消息体,即使有时实体头域的存在让人相信它们包括了.所有1XX(信息的),204(无内容的),和304(没有修改的)的应答都不能包括消息体.所有其他的应答必须包括消息体,虽然它可能长度为零.

4.4 消息的长度

一条消息的传输长度是消息体出现在消息中的长度,也就是说,当传输代码被处理以后.当一条消息包含消息体,实体的输长度有以下几条决定(以先后顺序):

1。任何回应信息不应包含在信息体中，如1xx，204,304回应和任何对头请求的回应。这种情况都是在头域结束后第一行为空白行,不管实体域是否出现。

2。传输代码头域(属于general-header域)出现的话而且有值而不是身份，那么传输长度就可以使用chunked大块来确定，除非信息由于连接关闭而中断了.

3。如果Content-Length头域(属于实体头)出现，那么它的值是信息体传输长度。如果传输头域和Content-Length头域都出现了，而长度不一致，那么Content-Length头域中的值就不该传。

4。如果被1.0代理传送的范围头域不能理解多部份/位范围；服务器必须采用1，2，3的方式界定信息体长度。

5。当服务器正在关闭连接.(正在关闭连接不能用来说明应答体的结束,因为它将导致服务器没有可能送回一个应答信号.)

为了与HTTP/1.0应用程序兼容,HTTP/1.1请求包含的消息体必须包括一个有效内容长度的头域,除非知道服务器适应HTTP/1.1.如果一个请求包含一个消息体并没有给出内容长度,那个服务器会应答400(错误的请求)如果他不能判断消息长度的话,或者应答411(要求成都)如果它坚持想要收到一个有效内容的长度.

所有的HTTP/1.1应用程序必须接受"CHUNKED"传输代码(3.6节),因此允许这种机制来处理消息当消息的程度不能被决定.

消息没有必要都不包括内容长度头域和non-identity传输代码.如果消息包括了一个non-identity传输代码,传输长度必须忽略.

当一个内容的长度在消息体允许的地方给出时,这个域值必须和消息体中八进制数一致.HTTP/1.1用户代理必须通报使用者当一个无效的长度被接受和发现.

4.5 常规头域

这儿有一些头域能适应一般的请求和应答消息,但是它没有应用渔船树种的实体.这些头域只应用于那些被发射的消息.

     常规的头域=高速缓存控制         ;14.9节
                |连接         ;14.10节
                |数据         ;14.18节
                |程序         ;14.32节
                |追踪         ;14.40节
                |传输编码     ;14.41节
                |升级         ;14.42节
                |路由         ;14.45节
                警告          ;14.46节

常规头域的名字的真正扩展必须和协议版本的变化相结合。然而，新的或实验性质的头域可能被赋予常规头域的意义，如果信息传输中的所有部分都承认它们为常规头域的话，未被承认的头于一般当实体头域看待。

5 请求

从客户机到服务器的请求,其首行包括利用资源的方式,区分资源的标识,以及协议的版本号
请求   =请求行                       ; 5.1节
       *((常规报头                    ; 4.5节
         |请求报头                    ; 5.3节
         实体报头)CRLF)              ; 7.1节
           CRLF
         [消息正文]                   ; 4.3节

5.1 请求行

请求-行的开头是方法标识,接下来是请求URL和协议版本号,以回车换行结束.各部分之间用空格符(SP)分隔,除了最后的回车换行外,不允许有回车(CR)和换行(LF).

请求-行 ==方式(空格) 请求URI(空格) HTTP版本号(回车换行)

5.1.1方法

方法标记指的是在请求URI所指定的资源上所实现的方式,这种方式是条件敏感的

扩展方式= 标记

资源允许的方法列表能由允许(Allow)报头域详细指定．既然被允许方法的设置可以动态的改变,返回的应答码总是通知客户机当前方法是否被允许.如果原服务器知道方法，但方法不被请求的资源允许，原服务器应当返回状态码405(方法不允许)．如果方法不被原服务器承认和实现,原服务器应当返回状态码501(没有实现）.获取(GET)和报头(HEAD)方法应当被所有的多功能服务器支持．其他所有的方法是可选的，然而，假若以上的方法没有实现，则他们必须被在第九章里所说明的同一种语法定义所实现．

5.1.2 请求URL

　　请求URL是一种全球统一的应用于资源请求的资源标识符（３.2 节）．
　
　　　　请求URL ="*"|绝对URL|绝对路径|主机authotity

请求URI的四个选项在一般情况下是互相关联的,星号"*"表示请求不是应用于某种特别的资源,而是服务器本身,只有当所用的方法不是资源必要的方法才是允许的.举例如下

选项(OPTIONS)*HTTP/1.1

当代理服务器产生请求时，绝对URI地址是不可缺少的．代理服务器被要求转寄来自高速缓冲存储器有效的请求或服务,返回应答．注意到代理服务器可以把请求转发给另一台代理服务器或直接转发给绝对URI地址说明的服务器．为了避免请求循环，代理服务器必须识别所有的服务器名字，包括任何别名，本地变异名，数字IP地址．请求行举例如下：
　　　　　
　　　　　ＧET http://www.w3.org/pub/www/TheProject.html HTTP/1.1

为了在未来的HTTP版本的所有请求中转换绝对URL地址，所有基于ＨTTP/1.1的服务器必须接受绝对URL地址的组成，虽然基于HTTP/1.1的客户机将只产生请求发给代理服务器

主机(authority)组成部分只是在连接方法(CONNECT)中用到（９.9节）．

最通用形式的请求ＵＲI用于标识在原服务器或网关上的资源.这种情况下，绝对ＵＲＬ路径必须作为请求ＵＲＬ传送（看３.２.１节，绝对路径），ＵＲＩ局域网地址(authority)(必须输入主机报头域．例如，希望直接得到原服务器顶层资源的客户机将在"ｗｗｗ．ｗ３．ｏｒｇ"主机的端口８０建立ＴＣＰ连接发送以下行：
　　
　　　GET /pub/WWW/TheProject.html HTTP/1.1
Host:www.w3.org

接下来是请求的其他部分，注意绝对路径不能是空的；假如没有初始的URI，必须给出"／"（服务器根目录）．

请求ＵＲＬ用在3.2.1节里说明的格式传输．如果用"%HEX　HEX"[42]码编码,为了正确的翻译请求，原服务器必须译码．对于有适当状态码的无效的请求，服务器必须给予应答．

当透明的代理服务器转发收到的请求ＵＲＬ地址给下一台网内的服务器时，禁止其重写 "绝对路径"部分,上面提到的用"／"代替空的绝对地址不在此例．

注：当原服务器不恰当的用非保留ＵＲＬ字符作保留用时，"禁止重写"规则防止
代理服务器更改请求的含义，实现程序将了解前面的一些HTTP/1.1代理服务器就将知道改写了请求ＵＲＩ．

5.2请求定义的资源

一个INTERNET请求所定义的精确资源由请求URL和主机报头域所决定.

当决定HTTP/1.1协议标识的资源时，不允许资源与请求主机不同的原服务器可以忽略主机报头域的值，（但看１９.６.１节了解支持HTTP/1.1主机上的另一种需求）.

基于主机的请求区分资源的服务器(有时指虚拟的主机或空白的主机名)必须用以下的规则决定HTTP/1.1请求所请求的资源．

１．如果请求URI是绝对地址，主机是请求URI的一部分．任何主机报头域应当忽略．
２．假如请求URI不是绝对地址，且请求包括一个主机报头域，则主机由该域的值所决定．
３．假如由规定１或规定２定义的主机是无效的主机，则应答当是一个400出错信息

为了找出真正被请求的资源，一个缺乏主机标识域的HTTP/1.0请求接收者可以尝试使用试探的方法（例如检测ＵＲＩ路径对于特定的主机是唯一的这个性质）．

５.3请求报头域

请求的报头域允许客户传递关于请求，客户自己的附加信息给服务器．这些域作为请求修饰成分，和程序语言中方法调用的参数有差不多的含义．

　　　请求报头　＝　接收(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节

随着协议版本的变化,请求报头域的名字可以可靠的扩展．然而新的或扩展的报头域可以给出请求报头域的语法，其前提是通信中所有部分承认它们是请求报头域．不被承认的报头域被当作实体报头域．

６应答

接收和翻译一个请求信息后，服务器发出一个HTTP应答信息．

　　　　　应答　　　＝状态行　                                 ;6.1节
　　　　　　　　　　　*((常规报头(general-header）                ; 4.5节
                       |应答报头(response-header)            ;6.2节
                       |实体报头(entity-header)CRLF)          ;7.1节
                             CRLF
                      [应答正文]                             ;7.2节

6.1 状态行

应答信息的第一行是状态行,由协议版本以及数字状态码和相关的文本说明组成,各部分间用空格符隔开，除了最后的回车或换行外，中间不允许有回车换行．
　　　　　
　　　状态行　＝　HTTP版本 SP状态码 SP 原因短语 CRLF

6.1.1状态码与注解

状态码是试图理解和满足请求的三位数字的整数码，这些码的完整定义在第十章．注解短语是特意给出的关于状态码的文本描述．状态码用于自动控制而注解短语是面向用户的．客户机不需要检查和显示注解短语．

状态码的第一位数字定义应答类型．后两位数字没有任何类型任务．第一位数字有五种值：

-1xx: 报告的                - 接收到请求,继续进程.
-2xx 成功                  - 操作成功的收到.
-3xx 重发              - 为了完成请求,必须采取进一步措施.
-4xx 客户端出错            - 请求包括错的顺序或不能完成.
-5xx 服务器出错            - 服务器无法完成显然有效的请求.

为HTTP/1.1定义的状态码单独的值，和一个相应的一系列注解短语的例子，介绍如下,这儿列出的注解短语只是建议――它们可以被相当的没有感情色彩的协议取代．

扩展码 =3DIGIT
注解短语=*

HTTP状态码是可扩展的．HTTP应用程序不需要理解所有已注册状态码的含义，尽管那样的理解显而易见是很合算的．但是，应用程序必须了解由第一位数字指定的状态码的类型，任何未被识别的应答应被看作是该类型的Ｘ00状态，有一个例外就是未被识别的状态码不能缓存．例如，如果客户机收到一个未被识别的状态码431，　Copyright www.cnpaf.net (2007). All Rights Reserved.
则可以安全的假定请求有错，且其对待应答的情况是仿佛客户端收到的是400状态码．在这种情况下，用户代理应当把实体和应答一起提交给用户，因为实体很可能包括说明不平常状态的人认可读的信息．

６.2应答报头域

应答头允许服务器传送应答的附加信息,这些信息不能放在状态行里.这些报头域给出有关服务器的信息以及请求URI指定的资源的下一步的通路．

随着协议版本的变化,应答报头可以可靠的扩展．而且，如果通信的所有组成部分都把它当作应答报头域,新的或试验性的应答报头域可以被给定应答报头域的含义，未被承认的报头域被当作实体报头域．

7。实体。

在未经特别规定的情况下，请求与应答的报文也可以传送实体。实体包括实体报头域与实体正文，而有些应答只包括实体报头。在本节内，接收者与发送者既可以指用户端，也可以指服务器，视由谁收发实体而定。

7。1 实体报文域

实体报文域定义了关于实体正文的维护信息（参数），或在无正文情况下定义了请求的资源。其中一些参数是可选的，一些则是由技术指标规定必须的。

扩展报头=报文报头

扩展报头机制允许在不改变协议的前提下定义额外的实体报头域，但不保证这些域在收端能够被识别。未被识别的域应当被接收者忽略，且必须被透明转发。

7。2 实体正文。

经由HTTP请求或应答发送的实体正文部分（如果存在的话）的格式与编码方式应由实体报文域决定。

实体正文= *八位字节

如4。3节所述，实体正文只有当报文正文存在时才存在。实体正文是通过对报文正文按某种保证安全性且便于传输的传输编码进行解码得到的。

7。2。1。类型。

对于报文中的实体正文而言，其数据类型由报头中的"内容类型"与"内容编码"域决定。也即定义了一个双层有序的编码模型：

实体正文=内容编码（内容类型（数据））

"内容类型"规定了基本数据的媒体类型。
"内容编码"则可用来指明对数据施加的任何附加的，通常以数据压缩为目的的编码方式，并将其作为所请求资源的一项属性。没有缺省的编码方式。

任一包含了实体正文的HTTP/1。1报文都应包括"内容类型"报头域，以定义正文的媒体类型。当且仅当"内容类型"域未给出媒体类型时，接收者才可以通过查看资源的内容，扩展名或URL来猜测其媒体类型。若媒体类型仍然未知，接收者应将其作为"应用/八位字节流"类来处理。

7。2。2 实体长度

报文的实体长度指的是在对报文进行传输编码前报文正文的长度。4。4节定义了确定报文正文传输长度的方法。

8。连接

8。1 持续连接。

8。1。1 目的

在持续连接之前，为获取每一URL都建立了独立的TCP 连接，这就加重了HTTP服务器的负担，易引起INTERNET阻塞。嵌入式图片与其它相关数据通常使用户在短时间内对同一服务器提交多个请求。目前已有针对这些性能问题的分析以及原型实施的结果[26]，[30]。实施的具体过程和对实际HTTP/1。1（RFC 2068）的测试均显示了良好的结果[39]。对其他方法也有了初步探究，如T/TCP [27]。

持续HTTP 连接有着诸多的优点：

--- 通过建立与关闭较少的连接，不仅节省了路由器与主机（客户机，服务器，代理服务器，网关，隧道或高速缓冲存储机）的CPU时间，还节省了主机用于TCP协议控制块的内存。

--- HTTP请求与应答可以进入连接流水线。流水线方式使得客户无须挨个等待应答即发起多个请求，从而更充分的利用了单个的TCP连接，减少了崩溃时间。

--- 在减少TCP连接中数据包个数的同时，使TCP有了充裕的时间来确定网络的拥塞状况，缓解了网络拥塞。

--- 因为无须在创建TCP连接握手上耗费时间，而使连续请求造成的延迟现象得到改善。

--- 由于出错不会导致TCP连接的关闭，HTTP可以更好的实现自我完善。使用较新版HTTP的用户会乐于尝试一些新功能，与旧版服务器通信时，则会在接到出错报告后用旧模式重试。

HTTP的实现应当采用持续连接。

8。1。2 总体操作

HTTP/1.1 与早期HTTP 版本的一个显著区别在于持续连接是任何HTTP连接的缺省方式。也就是说，除非另有指定，客户机总应当假定服务器会保持持续连接，即便在接到服务器的出错应答时也应如此。

持续连接提供了一种可以由客户机或服务器发信号终止TCP连接的机制。终止连接的信号利用了"连接"报头域（14.10节）。一旦出现了终止连接的信号，客户机便不可再向此连接提出任何新请求。

8。1。2。1 谈判

除非请求的连接报头域中包括了"终止连接"的符号，HTTP/1。1服务器总可以假定HTTP/1。1 客户机想要维持持续连接。如果服务器想在发出应答后立即终止连接，它应当发送一个含有终止要求的连接报头域。

无论是客户机或服务器发起终止连接，这都是本次连接的最后一个请求。

除非经明确指出，客户机与服务器不应假定低版HTTP会自动采用持续连接方式。请参见19。6。2节关于与HTTP/1。0客户机后向兼容性的有关内容。

为了维持持续连接，连接中的报文都必须有如4。4节所述的自定义报文长度（即不是由连接终止定义的长度）。

8。1。2。2 流水线

支持持续连接的客户机可以以流水线方式发送请求（即无须等待应答而发送多个请求）。服务器则必须将其应答按接到请求的顺序发出。

建立连接后立即采用持续连接与流水线方式的客户机应作好初次流水线尝试失败后重试的准备，而不可在持续连接尚未确定时就连续发送请求。客户机还必须为服务器在发出所有应答之前就结束连接的情况作好重发请求的准备。

客户机不应该用非等幂方法或非等幂方法序列（参见9。1。2节）连发请求。否则，过早终止的传输层连接会导致不确定的结果。

8。1。3 代理服务器

使代理服务器正确地实现14。10节所规定的连接报头域的属性是非常关键的。

代理服务器必须独立于它所连接的客户机，原服务器（或其它代理服务器）而发出持续连接的信号。每一持续连接仅针对传输层链接。

代理服务器不可与一台HTTP/1.0客户机建立HTTP/1。1持续连接（请参见RFC 2068 [33] 中关于HTTP/1。0客户机上实现"维持活跃态"报头问题的探讨及资料）

8。1。4 实际的考虑

服务器通常有一个时限值，超过一定时间即不再维系处于非活跃态的连接。代理服务器会选一个较高的值，因为客户机很可能会与同一服务器建立多个连接。持续连接方式的采用对于客户机与服务器的时限均未提出任何要求。当客户机或服务器希望超时终止时，它应按规范终止传输连接。客户端与服务器端应始终注意对方是否终止了连接，并适当的予以应答。若客户机或服务器未能及时检测到对方已终止了连接，将会造成不必要的网络资源浪费。

客户机，服务器，或代理服务器可能在任意时刻终止传输连接。比如，客户机可能正想发出新的请求，而此时服务器却决定关闭"闲置"的连接。在服务器看来，连接是在闲置状况下被关闭的，而客户机却以为请求在进行中。

这表明客户机，服务器与代理服务器必须有能力从非同步的连接终止事件中恢复。只要请求序列是等幂的（参见9。1。2节），客户端软件就应自动重新发起传输层连接并重传被废弃的请求序列。对非等幂方法或序列不可自动重试，但用户代理可以向手工操作员提供重发请求的机会。用户代理软件对应用程序基于句法理解的确认可以用来代替人工方式。若重试失败，则不应允许再试。

服务器在每次连接中只要有可能，总应至少应答一个请求。除非出于网络或客户端的故障，服务器不应在传送应答的中途断开连接。

使用持续连接的客户机应限制与某一服务器同时连接的个数。单用户客户机不应与任一服务器或代理服务器保持两个以上的连接。代理服务器与其它服务器或代理之间应维护2*N个连接，其中N是同时在线的用户数。设定这一规则是为了改进HTTP应答时间且避免拥塞。

8。2 报文传输要求、

8。2。1 持续连接与流量控制

HTTP/1。1服务器应当保持持续连接并使用TCP的流量控制机制来解决临时过载，而不是在终止连接后指望客户端的重试。后一方法会恶化网络阻塞。

8。2。2 监视连接中出错状态的报文

发送报文正文的HTTP/1。1（或更新）客户机应在传输请求的同时监视连接是否处于出错状态。若客户机发现了错误，它应当立即停止正文的传送。若正文是以块编码方式发送的（3。6节），可以用一长度为零的块和空报尾来提前标记报文结束。若正文前有"内容长度"报头，则客户机必须关闭连接。

8。2。3 100号状态的用途

100号状态的目的在于帮助那些发送含有请求正文的请求报文的客户机在发送请求正文之前推测服务器看到请求报头后是否愿意接收请求。有些时候，如果服务器不看正文就弃置报文的话，客户机对正文的发送就多此一举了。

对HTTP/1。1 客户机的要求：

--- 若客户机在发送请求正文之前等候100（继续）应答，则它必须发送填有"100--继续"期望的"期待请求"报头域（14。20节）。

--- 若客户机不需要发送请求正文，则它不得发送填有"100--继续"期望的"期待请求"报头域（14。20节）。

由于存在旧的实现方法，协议允许出现诸如客户机发出了"期望：100-继续" 却没接到417（期望失败）或100（继续）状态的混乱局面存在。因此，当客户机将这一报头域发给它从未接到100（继续）状态的原服务器（通常是通过代理）时，客户机不应在发送请求正文前无限期地等待。

对HTTP/1。1原服务器的要求：

--- 在接到"期望"请求报头域填有"100-继续"期望的请求时，原服务器必须以100（继续）状态应答并继续读入数据流，或者以终止状态码应答。原服务器在发送100（继续）应答之前不得等待。若以终止状态码应答，它既可关闭传输层连接，也可继续读入数据而丢弃请求的剩余部分。但此时它不得按客户机所请求的方式运行。

--- 如请求报文不含填有"100-继续"的"期望"报头域，原服务器不应发送100（继续）应答。当请求来自HTTP/1。0（或更早）客户机时也不得发送100（继续）应答。对此规定有一例外：为了与RFC 2068兼容，服务器对于未含填有"100-继续"的"期望"报头域的PUT或POST 请求可以应答100（继续）状态。这一例外的目的在于尽量减少由100（继续）状态的未申明等待引起的客户机处理延迟，仅适用于HTTP/1。1请求，和其它HTTP 版本的请求无关。

--- 若已经接到相应请求的部分或全部请求正文，原服务器可以免发100（继续）应答。

--- 一旦请求正文被收到处理，发出100（继续）应答的原服务器除非过早切断传输层连接，否则最终必须发送终止状态码。

--- 若原服务器接到不含填有"100-继续"的"期望"报头域的请求，该请求含有请求正文，而服务器又在从传输层连接读入正文之前就应答了终止状态码，则服务器不应在读完全部请求或客户机终止连接前关闭连接。否则，客户机可能无法可靠地接收应答报文。然而，这一要求在阐释中不应阻止服务器防卫拒绝服务的攻击或有严重缺陷的客户程序。

对代理服务器的要求：

--- 若代理服务器接到包含填有"100-继续"的"期望"报头域的请求，且代理服务器要么知道下一站服务器遵循HTTP/1。1或更高版协议，要么不知下一站服务器的HTTP版本，则它必须连同"期望"报头域一起转发此请求。

--- 若且代理服务器知道下一站服务器版本是HTTP/1。0或更低，则它不得转发此请求，而应应答以417（期望失效）状态。

--- 代理服务器应当维护一高速缓存，以记录新近访问到的下一站点服务器的HTTP版本号。

--- 若接到的请求来自于版本是HTTP/1。0（或更低）的客户机，不含填有"100-继续"的"期望"报头域的请求，则代理服务器不得转发100（继续）应答。这一要求可覆盖1xx应答转发的一般规则（参见10。1节）。

8．2．4 服务器过早关闭连接时客户机的行为

如果HTTP/1。1 客户机发出一条含有请求正文但不含填有"100-继续"的"期望"报头域的请求，并且客户机直接与HTTP/1。1原服务器相连，在从服务器处接到任何状态信息之前就发现连接被关闭，那么客户机应当重试请求。在重试时，客户机何以采用如下所述的"二进制指数后退算法"以确保获得可靠应答：

1．向服务器发起一新连接。
2．发送请求的报头。
3．初始化变量R为通往服务器的往返时间的估计值（比如基于建立连接的时间），或在无法估计往返时间时设为一常数值5秒。
4．计算T=R*（2**N），N为此前重试请求的次数。
5．等待服务器发来的出错应答或是T秒（两者中时间较短的）。
6．若没等到出错应答，T秒后发送请求正文。
7．若客户机发现连接被提前终止，转到第1步，直到请求被接受，接到出错应答，或是用户因不耐烦而终止了重试进程。

在任意环节上，客户机如果接到出错状态，
--- 不应再继续，并且
--- 如完成请求报文的发送则应终止连接

９方法定义

HTTP/1.1常规方法的定义如下.虽然这个定义可以展开,但附加的方法不能被假定分享和个别扩展的客户机和服务器同样的语义.

主机请求应答报头(14.23节)必须符合所有的HTTP/1.1请求.

9.1 安全和等幂(Idempotent)方法

9.1.1 安全方法

实现程序应当知道软件通过在Internet上的交互来扮演用户,且应该仔细的允许用户知道任何它们可能采取的行动,这些行动可能给他们自己或他人带来无法预料的结果.

特别的.这样的惯例已经形成,就是GET和HEAD方法除了补救外不应该有别的采取措施的含义.这些方法应该被看作"安全".这允许用户代理描绘其他方法,像POST,PUT,DELETE,在某种意义上,用户知道某种不安全的行为被请求的事实.

自然, 随着GET请求的实现,不可能保证服务器不产生副作用;事实上,一些动态的资源考虑到那样的特征.在这里重要的区别是用户没有请求副作用,因此不应该为此承担责任.

9.1.2 等幂方法

方法也可以等幂的性质,这种情况下(除了出错或终止问题)N>0个同样请求的副作用和单个请求一样.方法GET,HEAD,PUT,DELETE都有这种性质.而且,方法OPTIONS和TRACE不应该有副作用,等幂就是这样的含义.然而,有可能几个请求的序列是不等幂的,即使在那样的序列中所有方法单独实现都是等幂的(如果整个序列整体的实现结果总是相同的,即不因序列整体,部分的重新实现而变化,则序列是等幂的).例如,如果一个序列实现的结果依赖一个序列中后来可以修改的值,则该序列不是等幂的.

没有副作用的序列是等幂的(倘若在同样的资源配置下不同时操作)

9.2 OPTIONS(选项）

OPTIONS方法描述了在请求URI确定的请求/应答过程中通信条件是否可行的信息.该方法允许客户机确定条件或设备,其与资源或服务器的没有暗示资源操作或初始化资源重建的情况下的性能有关,

这种方法的应答是不能缓存的.

如果OPTIONS请求包括一个实体(用来指示内容长度或传输码的存在),接着媒体类型应该有一个内容内型域来确定.虽然这种规定对那样的主体没有定义任何功能,未来HTTP的扩展可以用OPTIONS域来安排更多细节性的有关服务器的询问.一台不支持扩展的服务器可以抛弃请求正文.

如果请求URI是一个星号("*"), OPTIONS请求特意应用于总的服务器而不是特定的服务资源.既然服务器的通信条件取决于资源,"*"请求只是作为"ping" 或 "no-op类型的方法才有用;它只能允许客户机测试服务器的性能.例如,这能被用来检测一台代理机即是否支持HTTP/1.1.

如果请求URI不是一个星号("*"), OPTIONS请求只是当和资源通信时应用于条件是否可能.

应答200应当包括表示服务器实现和可应用于资源的可选择的特征报头域,.可能包括这种规范定义未定义的扩展.规范没有定义正文,但未来HTTP的扩展可能会定义,商议内容可能会用于选择适当的应答格式.如果没有应答体被包括进来,应答必须包括一个值为零的内容长度域.

最大转发请求报头域可以用于请求过程中特定的代理机.当代理机收到可以继续传播的绝对URI的OPTIONS请求时,代理机必须检测最大转发域.如果最大转发域的值是零,代理机禁止转发信息.相反的,代理机将回答它自己的通信条件.如果是大于零的整数,当代理机转发请求时,该域的值将逐渐减小.如果请求中没有该域,则转发请求当中也会没有.

9.3 GET（获取）

GET方法重建信息的内容(正文的形式)由请求URI来确定.如果请求URI指数据产生的过程,它是在应答中产生,被当作正文返回的数据,而不是过程的源文本,除非文本碰巧是过程的输出.

如果请求信息包括 If-Modified-Since, If-Unmodified-Since,If-Match, If-None-Match, or If-Range报头域, GET的语义将变成"条件（conditial） GET". 只有在条件报头域(conditional header)所描述的环境下, 条件GET方法请求实体被传输. "条件GET"方法用于减少不必要的网络使用,这种使用允许在没有多种请求或客户机已经获传输数据的情况下刷新缓存实体.

如果请求信息包括范围（Range)报头域, GET方法的语义将变成"部分(partial)GET","部分GET"请求只要求传输部分实体,如14.35节指定的那样. 部分GET方式通过允许当客户端没有得到全部的传输数据时部分的重建数据来减少不必要的网络使用.

只有当GET请求碰到13章里所描述的支持HTTP缓存的设备时,应答才是可缓存的.

当使用表格形式时.请参看15.1.3节关于安全的考虑.

9.4 HEAD（报头）

除了应答中禁止返回消息正文外,HEAD方法与GET方法一样.包含在HTTP报头以后应答报头头请求的信息与POST去应答GET请求的信息是相同的.这种方法能用于获得关于实体更多的信息,没有传输实体正文本身的请求暗示了这种信息.这个方法常用来检查超文本链接的有效性,可到达性和最近的修正.

当包含在应答中的信息可以用来更新以前缓存的来自资源的实体时,对HEAD请求的应答是可缓存的.如果新域的值显示缓存的实体不同于当前的实体时(这将在内容长度,内容-MD5,ETAG或最后更新时间中表现出来),缓冲区就抛弃缓存的实体.

9.5 POST（张贴）
在POST 方法适用的请求中,原服务器接收附加在请求后的实体,该实体后作为请求行里请求URI指定的资源的次要部分,. POST 被设计为具有如下的功的统一的方法:

- 已有资源的注解.
- 在电子布告版,新闻组,邮箱或类似的主题组贴一些信息.
- 提供数据块,像确认表单数据处理的结果.
- 通过附加的操作扩充数据库.

POST方法实现的实际功能取决于服务器,且往往取决于请求URI.POST实体属于URI,就像文档属于包括它的目录,新闻主题属于它所在的新闻组,或纪录属于数据库.

POST方法实现的操作不会作用于URI可以鉴识别的资源.在这种情况下,无论2000(OK)还是2004(无目录)是合适的应答状态,取决于应答是否包括描述结果的实体.

如果原服务器上已经建立了资源,应答将是201(建立)且包括描述请求状态,指向新的资源的实体和一个本地报头(看14.30节).

这种方法的应答是不可缓存的,除非应答包括合适的缓冲控制或终止报头域.然而,303(看别的)应答可直接用于用户代理重建可缓存资源.

POST 请求必须像8.2节所描述的那样服从消息传输的需要.

参见15.1.3节关于安全性的考虑.

9.6 PUT（放置）

PUT方法要求所附实体存储在提供的请求URI下.假如请求URI指的是已经存在的资源,所附的实体应当被当作原服务器中已修改的版本. 假如请求URI指的不是已经存在的资源,而URI可以被客户代理定义成新的资源,原服务器可以建立该URI资源.假设建立了新资源,原服务器必须通过201(建立)应答通知用户代理.如果修改了已有资源,将发送200(OK)或204(无内容)应答表示请求的成功完成.如果对于该URI资源不能创建或修正,将给出合理的出错应答来反映问题所在.实体容器不能忽视任何不被理解或实现的内容-*(例如内容范围)报头,这时必须返回501(未实现)应答.

如果请求经过高速缓冲存储器和请求URI标识一个或多个当前缓存的实体,这些实体将被抛弃.这个方法的应答是不可缓存的.

POST和PUT请求基本的不同点反映在请求URI的不同意义.POST方法中的URI标识将处理附加实体的资源.资源可以是数据接收过程,一个网关和一些协议,或一个接收注解的分散的实体.与之相对照的是, PUT请求中的URI标识请求所附的实体-用户代理了解什么URI是有意的和服务器禁止试图应用请求于别的资源.假如服务器希望请求应用于不同的URI,

它必须是301(永久移动)应答;用户代理可以自己决定关于是否改变请求路由.

单个的资源可以被许多不同的URI确定.例如,一个主题可以有一个URI识别当前版本,这从URI识别每一个特定的版本分离开来.在这种情况下,PUT请求中一般的URI导致服务器,而其他的URI由原服务器定义.

HTTP/1.1没有定义PUT方法如何影响原服务器的状态.

PUT请求必须服从8.2节描述的信息传输需要.

除了特定的实体报头说明,POST方法中的实体头应该应用于POST方法创建或修改的资源.

9.7 DELETE（删除）

DELELE方法要求原服务器释放请求URI指向的资源.这种方法可以通过原服务器上人的强行干涉而制止(括其他手段).客户机不能担保操作已经实现了,即使从原服务器返回的状态码说明操作已经成功的完成.但如果当时应答未给出的话,服务器不应该表示成功,它打算释放资源或移到不能访问的位置.

假如应答包括描述状态的实体,成功的应答是200(OK),如果操作仍未制定,则应答为202(接收),如果操作已制定但应答不包括实体,则应答为204(无内容).

协议分析网

搜索

HTTP超文本传输协议-HTTP/1.1中文版(2)