rfc1945.htm

RFC文档

GET /pub/WWW/TheProject.html HTTP/1.0

	注意绝对路径不可以为空，如果URI中没有内容，也必须加上一个"/"（server root）。
	
	请求URI以编码字符串方式传输，有些字符可能在传输过程中被转义（escape），如变
成“%HEXHEX”形式。具体这方面内容请参见RFC1738[4]。原始服务器在正确解释请求
之前必须对请求URI进行解码。

5.2  请求标题域（Request Header Fields）

	请求标题域允许客户端向服务器端传递该请求的附加信息及客户端信息。该域做为请求
的修饰部分，遵照编程语言程序调用参数的语法形式。

Request-Header = Authorization			; Section 10.2
                      | From				; Section 10.8
                      | If-Modified-Since		; Section 10.9
                      | Referer				; Section 10.13
                      | User-Agent			; Section 10.15

	请求标题域名只有在与协议版本的变化结合起来后，才能进行可靠的扩展。实际上，新
的或实验中的标题域只要能被通讯各方识别，其语法就可使用，而无法识别的标题域都将被
视为实体域。

6.  回应（Response）

	在接收、解释请求消息后，服务器端返回HTTP回应消息。

Response			= Simple-Response | Full-Response

Simple-Response 	= [ Entity-Body ]

Full-Response 	= Status-Line				; Section 6.1
                         *( General-Header			; Section 4.3
                          | Response-Header		; Section 6.2
                          | Entity-Header )			; Section 7.1
                         CRLF
                         [ Entity-Body ]			; Section 7.2
	
	当请求是HTTP/0.9的或者服务器端只支持HTTP/0.9时，只能以Simple-Response方式
回应。如果客户端发送HTTP/1.0完整请求后，接收到的回应不是以状态行（Status-Line）
开头的，客户端将其视为简单回应，并相应对其进行分析。注意，简单请求只包括实体主体，
它在服务器端关闭连接时终止。

6.1  状态行（Status-Line）
	
	完整回应消息的第一行就是状态行，它依次由协议版本、数字形式的状态代码、及相应
的词语文本组成，各元素间以空格（SP）分隔，除了结尾的CRLF外，不允许出现单独的
CR或LF符。

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
	
	状态行总是以协议版本及状态代码开头，如：
		
"HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP
	（如，"HTTP/1.0 200"）。
	
这种表示方式并不足以区分完整请求和简单请求。简单回应可能允许这种表达式出现在
实体主体的开始部分，但会引起消息的误解。因为大多数HTTP/0.9的服务器都只能回
应"text/html"类型，在这种情况下，不可能产生完整的回应。


6.1.1 状态代码和原因分析（Status Code and Reason 
Phrase）

	状态代码（Status-Code）由3位数字组成，表示请求是否被理解或被满足。原因分析是
用简短的文字来描述状态代码产生的原因。状态代码用来支持自动操作，原因分析是为人类
用户准备的。客户端不需要检查或显示原因分析。
	
	状态代码的第一位数字定义了回应的类别，后面两位数字没有具体分类。首位数字有5
种取值可能：

o 1xx:：保留，将来使用。

o 2xx：成功 － 操作被接收、理解、接受（received, understood, accepted）。

o 3xx：重定向（Redirection）－ 要完成请求必须进行进一步操作。

o 4xx：客户端出错 － 请求有语法错误或无法实现。

o 5xx：服务器端出错 － 服务器无法实现合法的请求。

	HTTP/1.0的状态代码、原因解释在下面给出。下面的原因解释只是建议采用，可任意
更改，而不会对协议造成影响。完整的代码定义在第9节。
       Status-Code    = "200"   ; OK
                      | "201"   ; Created
                      | "202"   ; Accepted
                      | "204"   ; No Content
                      | "301"   ; Moved Permanently
                      | "302"   ; Moved Temporarily
                      | "304"   ; Not Modified
                      | "400"   ; Bad Request
                      | "401"   ; Unauthorized
                      | "403"   ; Forbidden
                      | "404"   ; Not Found
                      | "500"   ; Internal Server Error
                      | "501"   ; Not Implemented
                      | "502"   ; Bad Gateway
                      | "503"   ; Service Unavailable
                      | extension-code

       extension-code = 3DIGIT

       Reason-Phrase  = *<TEXT, excluding CR, LF>

	HTTP状态代码是可扩展的，而只有上述代码才可以被当前全部的应用所识别。HTTP
应用不要求了解全部注册的状态代码，当然，如果了解了更好。实际上，应用程序必须理解
任何一种状态代码，如果碰到不识别的情况，可根据其首位数字来判断其类型并处理。另外，
不要缓存无法识别的回应。

	例如，如果客户端收到一个无法识别的状态码431，可以安全地假定是请求出了问题，
可认为回应的状态码就是400。在这种情况下，用户代理应当在回应消息的实体中通知用户，
因为实体中可以包括一些人类可以识别的非正常状态的描述信息。


6.2  回应标题域（Response Header Fields）
	回应标题域中包括不能放在状态行中的附加回应信息。该域还可以存放与服务器相关的
信息，以及在对请求URI所指定资源进行访问的下一步信息。

Response-Header = Location				; Section 10.11
| Server				; Section 10.14
| WWW-Authenticate	; Section 10.16
	
	回应标题域名只有在与协议版本的变化结合起来后，才能进行可靠的扩展。实际上，新
的或实验中的标题域只要能被通讯各方识别，其语法就可使用，而无法识别的标题域都将被
视为实体域。


7.  实体（Entity）
	
	完整请求和完整回应消息可能会传输请求或回应中的实体。实体由实体标题
（Entity-Header）域、（通常还有）实体主体（Entity-Body）组成。从这种角度看，客户端
与服务器都将扮演发送方及接收方的角色。某一时刻的角色定位则取决于在这个时刻谁在发
送实体，而谁又在接收实体。

7.1  实体标题域（Entity Header Fields）

	实体标题域中定义了一些可选的元信息，如有无实体、请求资源。

Entity-Header  = 	Allow					; Section 10.1
| Content-Encoding			; Section 10.3
| Content-Length			; Section 10.4
| Content-Type				; Section 10.5
| Expires					; Section 10.7
| Last-Modified			; Section 10.10
| extension-header

extension-header = HTTP-header

	扩展标题（extension-header）机制允许在不改变协议的前提下定义附加的实体标题域，
但是不能假定接收方可以识别这些域。对于不可识别的标题域，接收方一般是忽略不管，而
代理则继续将其向前推送。

7.2  实体主体（Entity Body）

	与HTTP请求或回应一起发送的实体主体的格式和编码信息都在实体标题域
（Entity-Header）中定义。

Entity-Body    = *OCTET

	实体主体只在请求方法有要求时才会被放在请求消息中。请求消息标题域处的内容长度
标题域（Content-Length header field）的标志将指明请求中的实体主体是否存在。包含实体
主体的HTTP/1.0请求必须包含合法的内容长度标题域。
	
	对回应消息来说，消息中是否包含实体主体取决于请求方法和回应代码。所有的HEAD
请求方法的回应都不应包括主体，即便是实体标题域中指明有主体也一样。在主体中不应包
括这些回应信息，全部1xx（信息）、204（无内容）和304（未修改）。而其它的回应必须包
括实体主体或其内容长度标题（Content-Length header）域的定义值为0。

7.2.1 类型（Type）

	当消息中包括实体主体，主体的数据类型由标题域中的内容类型（Content-Type）和内
容编码（Content-Encoding）决定。定义了二层顺序编码模式：

entity-body := Content-Encoding( Content-Type( data ) )

	内容类型（Content-Type）指定了下列数据的介质类型（media type）。内容编码
（Content-Encoding）可用于指示附加内容解码方式，通常用于有数据压缩属性的被请求资
源。内容编码的缺省值是none。
	
	任何包括实体主体的消息必须含有内容类型（Content-Type）标题域，以定义主体的类
型。只有当内容类型标题域中没有给出介质类型时，如简单回应消息，接收方可能对该URL
所指定的资源进行判断，如其内容及扩展名等等，从而猜测出该主体的介质类型。如果还无
法确定介质类型，接收方应当将其视为" application/octet-stream"型。

7.2.2 长度（Length）

	当实体主体被包括在消息中，主体长度可以有两种方式确定。如果内容长度
（Content-Length）标题域存在，其字节值就是实体主体长度；否则，其主体长度由服务端
关闭连接时确定。
	由于服务端无法在连接关闭时发送回应信息，所以不能用关闭连接来指示请求主体的结
束。因而，HTTP/1.0请求如果包含主体，就必须在内容长度（Content-Length）标题域中给
出合法的值。如果请求包括实体主体，且内容长度没指定，服务端将无法识别或无法从其它
域中计算出其主体长度，在这种情况下，服务端将会返回400（非法请求）回应。
	注意：一些老的服务器在发送包含由服务器端动态插入的数据流文件时，支持非法的内
容长度使用。要强调的是，未来版本的HTTP协议将会很快改变这种情况。除非客户端自己
知道正在从一个支持它的服务器端得到回应，否则不应依赖于内容长度域的正确性。

8.  方法定义（Method Definitions）
	
	通用的HTTP/1.0的方法集将在下面定义，虽然该方法集可以扩展，但并不保证附加的
方法能够被扩展的客户端和服务器端所支持。

8.1  GET
	
	GET方法就是以实体方式得到由请求URI所指定资源的信息。如果请求URI只是一个
数据产生过程，那么最终要在回应实体中返回的是由该处理过程的结果所指向的资源，而不
是返回该处理过程的描述文字，除非那段文字恰好是处理的输出。
	如果请求消息包含If-Modified-Since标题域，GET方法的语法就变成“条件GET”，即
“（conditional GET）”。 条件GET方法可以对指定资源进行判断，如果它在If-Modified-Since
标题域（见10.9节）中的指定日期后发生了更新，才启动传输，否则不传输。这种条件GET
允许被缓存的实体在不必经过多次请求或不必要的数据传输就能进行刷新，从而有助于降低
网络负载。

8.2  HEAD
	
	HEAD方法与GET几乎一样，区别在于，HEAD方法不让服务器在回应中返回任何实
体。对HEAD请求的回应部分来说，它的HTTP标题中包含的元信息与通过GET请求所得
到的是相同的。通过使用这种方法，不必传输整个实体主体，就可以得到请求URI所指定
资源的元信息。该方法通常用来测试超链接的合法性、可访问性及最近更新。
	与条件GET不同，不存在所谓的“条件HEAD”，即"conditional HEAD"。即使在HEAD
请求中指定If-Modified-Since标题域，它也会被忽略。

8.3  POST
	
	POST方法用来向目的服务器发出请求，要求它接受被附在请求后的实体，并把它当作
请求队列（Request-Line）中请求URI所指定资源的附加新子项。POST被设计成用统一的
方法实现下列功能：

o 对现有资源的注释（Annotation of existing resources）；

o 向电子公告栏、新闻组，邮件列表或类似讨论组发送消息；

o 提交数据块，如将表格（form [3]）的结果提交给数据处理过程；

o 通过附加操作来扩展数据库。

	POST方法的实际功能由服务器来决定，而且通常依赖于请求URI。在POST过程中，
实体是URI的从属部分，就好象文件从属于包含它的目录、新闻组文件从属于发出该文件
的新闻组、记录从属于其所在的数据库一样。
	成功的POST不需要在原始服务器创建实体，并将其做为资源；也不需要为未来的访问
提供条件。也就是说，POST方法不一定会指向URI指定的资源。在这种情况下，200（成
功）或204（无内容）都是适当的回应状态，取决于实际回应实体中对结果的描述。
	如果在原始服务器上创建了资源，回应应是201（已创建），并包含一个实体
（对"text/html"类型最为适合），该实体中记录着对新资源请求的状态描述。
	在所有的HTTP/1.0的POST请求中，必须指定合法的内容长度（Content-Length）。如
果HTTP/1.0服务器在接收到请求消息内容时无法确定其长度，就会返回400（非法请求）
代码。
	应用程序不能缓存对POST请求的回应，因为做为应用程序来说，它们没有办法知道服
务器在未来的请求中将如何回应。
	
9.  状态代码定义（Status Code Definitions）
	
	每个状态代码都将在下面描述，包括它们将对应哪个方法、以及回应中需要的全部元信
息。

9.1  消息1xx（Informational 1xx）

	该类状态代码用于表示临时回应。临时回应由状态行（Status-Line）及可选标题组成，
由空行终止。HTTP/1.0中没有定义任何1xx的状态代码，所以它们不是对HTTP/1.0请求的
合法回应。实际上，它们主要用于实验用途，这已经超出本文档的范围。

9.2  成功2xx（Successful 2xx）

	表示客户端请求被成功接收、理解、接受。

200 OK
	请求成功。回应的信息依赖于请求所使用的方法，如下：

GET		要请求的资源已经放在回应的实体中了。

HEAD		没有实体主体，回应中只包括标题信息。