RFC1945 超文本传输协议--HTTP/1.0 之二

5. 请求（Request）
	从客户端到服务器端的请求消息包括，消息首行中，对资源的请求方法、资源的标识符
及使用的协议。考虑到局限性更大的HTTP/0.9的向后兼容问题，有两种合法的HTTP请求
格式：

Request			= Simple-Request | Full-Request

Simple-Request	= "GET" SP Request-URI CRLF

Full-Request		= Request-Line		; Section 5.1
*( General-Header		; Section 4.3
| Request-Header		; Section 5.2
| Entity-Header )		; Section 7.1
CRLF
[ Entity-Body ]		; Section 7.2

	如果HTTP/1.0服务器收到简单请求，它必须回应一个HTTP/0.9格式的简单回应。
HTTP/1.0的客户端有能力接收完整回应，但不能产生简单请求。

5.1  请求队列（Request-Line）
	
	请求队列以一个方法符号开头，跟在请求URI及协议版本的后面，以CRLF为结尾。
该元素用空格SP分隔。除了最后的CRLF，不允许出现单独的CR或LF符。

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

	注意，简单请求与完整请求的请求队列之间的区别在于是否有HTTP版本域和是否可以
使用除GET以外的其它方法。


5.1.1 方法（Method）

	方法代号指明了将要以何种方式来访问由请求URI指定的资源。方法是大小写敏感的。

Method		= "GET"　				; Section 8.1
|"HEAD"				; Section 8.2
| "POST"				; Section 8.3
| extension-method

       extension-method = token
	
	可以访问指定资源的方法列表是可以动态变化的；如果用某种方法访问资源被拒绝，客
户端可从回应中的返回码得到通知。服务器端在方法无法识别或没有实现时，返回状态代码
501（尚未没实现）。

	这些方法被HTTP/1.0的应用程序普遍使用，完整定义请参见第8节。

5.1.2 请求URI（Request-URI）
	
	请求URI就是统一资源标识符（3.2节），用来标识要请求的资源。

Request-URI		= absoluteURI | abs_path

	上面两种请求URI方式可根据实际的请求方式选择使用。
	绝对URI（absoluteURI）格式只在代理（proxy）在产生请求时使用。代理的责任是将
请求向前推送，并将回应返回。如果请求是GET或HEAD方式，而且之前的回应被缓存，
如果代理忽略标题域的过期信息限制，它可能使用缓存中的消息。注意，代理可能将请求推
送至另外一个代理，也可将请求直接送至绝对URI中所指定的目的服务器。为了避免请求
循环，代理必须能够识别它的所有服务器名，包括别名、本地变量及数字形式的IP地址。
下面是一个请求队列的例子：GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0

	最普通的请求URI形式就是原始服务器或网关用来标识资源的方式。在这种方式下，
只有给出绝对路径的URI才能被传输（见3.2.1节）。例如，如客户端希望直接从原始服务
器上接收资源，它们将产生一个与主机"www.w3.org"80端口的TCP连接，并在完整请求之
后发送下面的命令：

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		没有实体主体，回应中只包括标题信息。

POST		实体（描述或包含操作的结果）。

201 Created
	
请求完成，结果是创建了新资源。新创建资源的URI可在回应的实体中得到。原
始服务器应在发出该状态代码前创建该资源。如果该操作不能立即完成，服务器必
须在该资源可用时在回应主体中给出提示，否则，服务器端应回应202（可被接受）。

在本文定义的方法，只有POST可以创建资源。

202 Accepted
		
请求被接受，但处理尚未完成。请求可能不一定会最终完成，有可能被处理过程随
时中断，在这种情况下，没有办法在异步操作中重新发送状态代码。

202回应是没有义务的，这样做的目的是允许服务器不必等到用户代理和服务器间
的连接结束，就可以响应其它过程的请求（象每天运行一次的，基于批处理的过程）。

在某些回应中返回的实体中包括当前请求的状态指示、状态监视器指针或用户对请
求能否实现的评估信息。

204 No Content

服务器端已经实现了请求，但是没有返回新的信息。如果客户是用户代理，则勿需
为此更新自身的文档视图。该回应主要是为了在不影响用户代理激活文档视图的前
提下，进行script语句的输入及其它操作。该回应还可能包括新的、以实体标题形
式表示的元信息，它可被当前用户代理激活视图中的文档所使用。

9.3  重定向（Redirection 3xx）
		
该类状态码表示用户代理要想完成请求，还需要发出进一步的操作。这些操作只有
当后跟的请求是GET或HEAD时，才可由用户代理来实现，而不用与用户进行交
互。用户代理永远也不要对请求进行5次以上的重定向操作，这样可能导致无限循
环。

300 Multiple Choices
		
该状态码不被HTTP/1.0的应用程序直接使用，只是做为3xx类型回应的缺省解释。

存在多个可用的被请求资源。

除非是HEAD请求，否则回应的实体中必须包括这些资源的字符列表及位置信息，
由用户或用户代理来决定哪个是最适合的。

如果服务器有首选，它应将对应的URL信息存放在位置域（Location field）处，
用户代理会根据此域的值来实现自动的重定向。

301 Moved Permanently
		
请求到的资源都会分配一个永久的URL，这样就可以在将来通过该URL来访问此
资源。有编辑链接功能的客户端会尽可能地根据服务器端传回的新链接而自动更新
请求URI。

新的URL必须由回应中的位置域指定。除非是HEAD请求，否则回应的实体主体
（Entity-Body）必须包括对新URL超链接的简要描述。

如果用POST方法发出请求，而接收到301回应状态码。在这种情况下，除非用户
确认，否则用户代理不必自动重定向请求，因为这将导致改变已发出请求的环境。

注意：当在接收到301状态码后而自动重定向POST请求时，一些现存的用户代理
会错误地将其改为GET请求。

302 Moved Temporarily
		
请求到的资源在一个不同的URL处临时保存。因为重定向有时会被更改，客户端
应继续用请求URI来发出以后的请求。

新的URL必须由回应中的位置域指定。除非是HEAD请求，否则回应的实体主体
（Entity-Body）必须包括对新URL超链接的简要描述。

如果用POST方法发出请求，而接收到302回应状态码。在这种情况下，除非用户
确认，否则用户代理不必自动重定向请求，因为这将导致改变已发出请求的环境。

注意：当在接收到302状态码后而自动重定向POST请求时，一些现存的用户代理
会错误地将其改为GET请求。

304 Not Modified
		
如果客户端成功执行了条件GET请求，而对应文件自If-Modified-Since域所指定
的日期以来就没有更新过，服务器应当回应此状态码，而不是将实体主体发送给客
户端。回应标题域中只应包括一些相关信息，比如缓存管理器、与实体最近更新
（entity's Last-Modified）日期无关的修改。相关标题域的例子有：日期、服务器、
过期时间。每当304回应中给出的域值发生变化，缓存都应当对缓存的实体进行更
新。

9.4  客户端错误（Client Error ）4xx

	4xx类的状态码表示客户端发生错误。如果客户端在收到4xx代码时请求还没有完成，
它应当立即终止向服务器发送数据。除了回应HEAD请求外，不论错误是临时的还是永久
的，服务器端都必须在回应的实体中包含错误状态的解释。这些状态码适用于任何请求方法。

	注意：如果客户端正在发送数据，服务器端的TCP实现应当小心，以确保客户端在关
闭输入连接之前收到回应包。如果客户端在关闭后仍旧向服务器发送数据，服务器会给客户
端发送一个复位包，清空客户端尚未处理的输入缓冲区，以终止HTTP应用程序的读取、解
释活动。

400 非法请求（Bad Request）
		
如果请求的语法不对，服务器将无法理解。客户端在对该请求做出更改之前，不应
再次向服务器重复发送该请求。

401 未授权（Unauthorized）
	
请求需要用户授权。回应中的WWW-Authenticate标题域（10.16节）应提示用户
以授权方式请求资源。客户端应使用合适的授权标题域（10.2节）来重复该请求。如果
请求中已经包括了授权信任信息，那回应的401表示此授权被拒绝。如果用户代理在多
次尝试之后，回应一样还是返回401状态代码，用户应当察看一下回应的实体，因为在
实体中会包括一些相关的动态信息。HTTP访问授权会在11节中解释。

403 禁止（Forbidden）
		
服务器理解请求，但是拒绝实现该请求。授权对此没有帮助，客户端应当停止重复
发送此请求。如果不是用HEAD请求方法，而且服务器端愿意公布请求未被实现原因
的前提下，服务器会将拒绝原因写在回应实体中。该状态码一般用于服务器端不想公布
请求被拒绝的细节或没有其它的回应可用。

404 没有找到（Not Found）
		
服务器没有找到与请求URI相符的资源。404状态码并不指明状况是临时性的还是
永久性的。如果服务器不希望为客户端提供这方面的信息，还回应403（禁止）状态码。

9.5  服务器错误（Server Error ）5xx

回应代码以‘5’开头的状态码表示服务器端发现自己出现错误，不能继续执行请
求。如果客户端在收到5xx状态码时，请求尚未完成，它应当立即停止向服务器发送数
据。除了回应HEAD请求外，服务器应当在其回应实体中包括对错误情况的解释、并
指明是临时性的还永久性的。

这类回应代码没有标题域，可适用于任何请求方法。

500 服务器内部错误（Internal Server Error）

服务器碰到了意外情况，使其无法继续回应请求。

501 未实现（Not Implemented）

服务器无法提供对请求中所要求功能的支持。如果服务器无法识别请求方法就会回
应此状态代码，这意味着不能回应请求所要求的任何资源。

502 非法网关（Bad Gateway）

		充当网关或代理的服务器从要发送请求的上游（upstream）服务器收到非法的回应。

503 服务不可用（Service Unavailable）

服务器当前无法处理请求。这一般是由于服务器临时性超载或维护引起的。该状态
码暗示情况是暂时性的，要产生一些延迟。
注意：503状态码并没有暗示服务器在超载时一定要返回此状态码。一些服务器可
能希望在超载时采用简单处理，即断掉连接。

10.  标题域定义（Header Field Definitions）
	
本节定义了HTTP/1.0标题域常用的语法及语义。无论是发送方还是接收方，都有
可能做为客户端或服务器端，具体角色取决于在此时刻究竟是谁在接收、谁在发送。

10.1  允许（Allow）

	表示由请求URI所指定的资源支持在Allow实体标题域中列出的方法，目的是让接收
方更清楚地知道请求此资源的合法方式。Allow标题域不允许在POST方法中使用，如果非
要这么做，将被忽略。

Allow		= "Allow" ":" 1#method

Example of use:

       Allow: GET, HEAD

该域不能防止客户端尝试其它方法。但实际上由Allow标题域中的值所表示的指示
信息是有用的，应当被遵守。实际的Allow方法集在每次向原始服务器上发出请求时定
义。
由于用户代理（user agent）可能出于其它目的与原始服务器通讯，做为代理（proxy）
来说，即使无法识别请求所指定的所有方法，也不能修改该请求的Allow标题域。
Allow标题域并不表示服务器实现了哪些方法。

10.2  授权（Authorization）

	通常，用户代理在收到401（未授权）回应时，可能（也可能不会）希望服务器对其授
权。如果希望授权，用户代理将在请求中加入授权请求标题（Authorization request-header）
域。授权域值由信任证书组成，其中有对用户代理所请求资源领域的授权信息。

Authorization  = "Authorization" ":" credentials

	HTTP访问授权在11节中描述。如果请求中的授权指定了一个范围，那在此范围的其
它请求也都具有相同的信任关系。

	对包含授权信息域的请求来说，其回应是不能被缓存的。

10.3  内容编码（Content-Encoding）

	内容编码的实体标题域（entity-header）用作介质类型（media-type）的修饰符。它指明
要对资源采用的附加内容译码方式，因而要获得内容类型（Content-Type）标题域中提及的
介质类型，必须采用与译码方式一致的解码机制。内容编码主要用来记录文件的压缩方法。
各种压缩方法将在后面列出。

Content-Encoding = "Content-Encoding" ":" content-coding

内容译码（Content codings）在3.5节中定义，例如：

Content-Encoding: x-gzip


内容编码是请求URI指定资源的一个特性，一般来说，资源用编码方式存储，只有在
通过解码变换以后才能使用。

10.4  内容长度（Content-Length）

	内容长度（Content-Length）实体标题域指明了发送到接收方的实体主体（Entity-Body）
长度，用字节方式存储的十进制数字表示。对于HEAD方法，其尺寸已经在前一次GET请
求中发出了。
	
Content-Length = "Content-Length" ":" 1*DIGIT

例如：

Content-Length: 3495

	不论实体是何种介质类型，应用程序都将通过该域来判定将要传输的实体主体尺寸。所
有包括实体主体的HTTP/1.0的请求消息都必须包括合法的内容长度值。 
	
	任何0以上（包括0）的值都是合法的内容长度值。在7.2.2节描述了当内容长度值没
有给出时，如何决定回应实体主体长度的方法。

	注意：该域的含义与在MIME中定义的有重要区别。在MIME中，它是可选域，只
在"message/external-body"内容类型中使用；而在HTTP中，在实体被传输前，该域就决定
了实体的长度。

10.5  内容类型（Content-Type）

内容类型实体标题域指明了发送给接收方的实体主体长度。对于HEAD方法，介质类
型已经在前一次GET请求中发出了。

Content-Type   = "Content-Type" ":" media-type

介质类型在3.6节中定义，如下例：

Content-Type: text/html

	更多关于介质类型的讨论在7.2.1节。

10.6  日期（Date）

	日期普通标题（Date general-header）域表示消息产生的时间，其语法与RFC822中定义
的orig-date是一样的。该域值是HTTP型日期，在3.3节中描述。

Date			= "Date" ":" HTTP-date

例如：

Date: Tue, 15 Nov 1994 08:12:31 GMT

	如果直接通过用户代理（如请求）或原始服务器（如回应）的连接接收到消息，日期可
以认为是接收端的当前时间。然而，对于原始服务器来说，时间对其回应缓存的处理非常重
要，所以，原始服务器的回应总是包括日期标题。客户端只有在发送带实体的消息时，才可
向服务器发送日期标题域，比如POST请求。如果接收到的消息被接收方或网关通过有日期
要求的协议缓存起来时，该消息即使没有日期标题域，接收方也会为其分配一个。

	理论上，日期应当在实体产生时生成，而实际上，日期可能在消息产生过程的任意时间
生成，而不会造成任何不利的影响。

	注意：早期版本错误地将此域值定义为实体主体封装时的日期。这已经被实际应用所更
正。

10.7  过期（Expires）
	
	过期实体标题域中的日期/时间值指定了实体过期的时间。这为信息提供方提供了使信
息失效的手段。当超过此期限时，应用程序不应再对此实体进行缓存了。过期并不意味着原
始资源会在此期限后发生改变或停止存在。在实际应用中，信息提供者通过检查过期标题域
中所指定的时间，从而获知或预测资源将会发生改变的确切日期。该格式用的是绝对日期时
间（3.2节）。

Expires		= "Expires" ":" HTTP-date

例如：

Expires: Thu, 01 Dec 1994 16:00:00 GMT

如果给定日期比日期标题中的要早（或相同），接收方不应缓存附加的实体。如果资源
是动态自然生成的，象有些大量数据的处理，资源的实体应当被加上一个适当的过期时间值。
	
	过期域并不能强制用户代理对其进行刷新或重新载入资源，它只用于缓存机制。当对已
初始化过的资源发出新请求时，该机制才检查该资源的过期状态。
	
	用户代理通常都有历史记录机制，如“后退”按钮和历史记录列表。该种机制可以用来
重新显示某次对话（session）之前已经获取的实体信息。在缺省状态下，过期域不对历史机
制使用。除非用户在配置用户代理时指定了对历史文件进行过期刷新，否则，只要实体还保
存着，历史机制就能显示它，不论该实体是否已经过期。

	注意：应用程序应兼容对过期标题非法或错误的实现，如碰到0值或非法的日期格式，
应用程序应将其视为“立即过期（expires immediately）”。虽然这些值不符合HTTP/1.0，对
于一个健壮的应用来说，还是必要的。

10.8  来自（From）
	
	From请求标题域，如果给出来，则应包括一个使用此用户代理的人类用户的Internet　
e-mail地址。该地址应当能被系统识别，就象RFC822[7]（已经更新为RFC1123[6]）中的邮
箱定义一样。

From		= "From" ":" mailbox

例如：

From: webmaster@w3.org

	该标题域可能用来做为登录目的使用，以确定对某资源的请求是否合法。它不应用于不
安全的访问保护。该域的解释是，请求已按请求人指定的行为方式完成，而该请求人将为此
种方式负责。特殊情况下，机器人（robot）代理也应包括此标题域，域中注明是谁运行它
的，这样，当接收端发生任何问题时，都可以同这个人取得联系。
	
	该域中的Internet e-mail地址可以与处理该请求的Internet主机分离。例如，当请求通过
代理（proxy）时，应使用原始的传输地址。
	
	注意：客户端在没有得到用户批准时，不应发送From标题域，因为这样做可能会产生
用户隐私及网站安全方面的问题。强烈建议在请求之前提供手段以禁止（disable）、允许
（enable）、修改（modify）该域的值。

10.9  从何时更改（If-Modified-Since）

If-Modified-Since请求标题域和GET方法一起使用，用于处理下面情况：当在该域指定
的日期以来，请求资源没有发生任何变更。这时，服务器将不会下传该资源的拷贝，即，回
应不带任何实体主体，只是304状态码（未修改）。

If-Modified-Since = "If-Modified-Since" ":" HTTP-date

例如：

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

	条件GET方法可以请求服务端将在If-Modified-Since标题域中的指定日期后发生变更
的指定资源下传，也就是说，如果资源没发生变化，就不下传了。其算法如下：

a)	如果请求的回应状态不是200（成功）码或它传过来的If-Modified-Since中的
日期不合法，此时按照普通GET来回应。如果日期比服务器的当前时间还要
晚，则是非法时间。
b)	如果资源在If-Modified-Since日期以后有变化，回应也和普通GET一样
c)	如果资源在If-Modified-Since日期以后没变化，服务器端将回应304（未修改）。
注：该日期应是合法的。
这样做的目的是为了以最小的代价，对被缓存信息进行有效更新。

10.10  最近更改（Last-Modified）

	Last-Modified实体标题域表示由发送方设定的资源最近修改日期及时间。该域的精确定
义在于接收方如何去解释它：如果接收方已有此资源的拷贝，但此拷贝比Last-Modified域
所指定的要旧，该拷贝就是过期的。

Last-Modified  = "Last-Modified" ":" HTTP-date

例如：

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

	该标题域的精确含义取决于发送方的执行方式及原始资源的自然状态。对于文件来说，
可能是它在文件系统的last-modified时间。对于包含多个组成部分的实体来说，可能是组成
部分中最新的last-modify时间。对数据库网关来说，可能是记录的last-update时间戳。对于
虚（virtual）对象来说，可能是内部状态的最近改变时间。
	
	原始服务器不应发送比服务器消息产生时间更晚的Last-Modified日期，因为该消息会
导致服务器在未来的某个时间内，用消息原始的日期对该域值进行再次更新。

10.11  位置（Location）

	Location回应标题域定义了由请求URI指定的资源的位置。对于3xx（重定向）回应，
位置域必须能帮助服务器找到相应的URL，以实现对资源的重定向。只允许用绝对URL。

Location       = "Location" ":" absoluteURI

例如：

Location: http://www.w3.org/hypertext/WWW/NewLocation.html

10.12  注解（Pragma）

	Prama普通标题域包括一些可能对请求/回应链中的任一接收方有用的特殊指示信息。
从协议角度看，所有的注解指示了一些特定的可选行为，事实上，一些系统可能会要求行为
与指示一致。

Pragma 			= "Pragma" ":" 1#pragma-directive

pragma-directive	= "no-cache" | extension-pragma
extension-pragma 	= token [ "=" word ]

	当"no-cache"出现在请求消息中时，应用程序应当向原始服务器推送此请求，即使它已
经在上次请求时已经缓存了一份拷贝。这样将保证客户端能接收到最权威的回应。它也用来
在客户端发现其缓存中拷贝不可用或过期时，对拷贝进行强制刷新。

	不管注解（Pragma）指示信息对代理（proxy）及网关（gateway）应用程序如何重要，
它必须能穿越这些应用，因为该信息可能对请求/回应链上的其它接收方有用。实际上，如
果注解与某个接收方无关，它应当被该接收方忽略。

10.13 提交方（Referer）

	提交方请求标题域是出于服务器端利益方面的考虑，允许客户端指明该链接的出处，即
该指向资源地址的请求URI是从哪里获得的。这样，服务器将产生一个备份链接（back-links）
列表，用于维护受欢迎的资源、登录、缓存优化等活动。

Referer		= "Referer" ":" ( absoluteURI | relativeURI )

例子：

Referer: http://www.w3.org/hypertext/DataSources/Overview.html

	如果只给了部分URI，应当参照请求URI来解释它。URI不能包括段（fragment）。
	
	注意：因为链接的原代码可能暴露一些隐私信息，因此强烈建议由用户来决定是否发送
提交人域。例如，浏览器客户端有个选项可以用来进行离线浏览，可以使能或禁止提交人或
表单信息的发送。

10.14  服务器（Server）

	服务器回应标题域包含由原始服务器用来处理请求的软件信息。该域可包含多个产品标
识（3.7节）及注释以标识服务器及重要的子产品。按照习惯，产品标识将按其应用的重要
顺序排列。

Server         = "Server" ":" 1*( product | comment )

例如：

Server: CERN/3.0 libwww/2.17

如果回应要通过代理来推送，代理应用程序不应将它自己的数据加入产品列表。

注意：一些指定服务器软件的版本有启示作用，因为这些版本的软件存在一些安全漏洞，
将使服务器更易受到攻击。提倡服务器软件在实现时，将此域变成可以进行配置的选项。

	注意：有些服务器不遵守服务器域产品标识的语法约束。

10.15  用户代理（User-Agent）
	
	用户代理请求标题域包含用户原始请求的信息，这可用于统计方面的用途。通过跟踪协
议冲突、自动识别用户代理以避免特殊用户代理的局限性，从而做到更好的回应。虽然没有
规定，用户代理应当在请求中包括此域。该域可包含多个产品标识（3.7节）及注释以标识
该代理及其重要的子产品。按照习惯，产品标识将按子产品对应用的重要性顺序排列。

User-Agent     = "User-Agent" ":" 1*( product | comment )

例如：

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

	注意：现存有些代理应用将它们的产品信息回到了用户代理域中，这种方法不值得提倡，
因为这样做会使机器在解释这些信息时产生混淆。
	注意：现在有些客户端不遵守用户代理域中产品标识的语法约束。

10.16  WWW-授权（WWW-Authenticate）

	WWW-授权回应标题域必须被包括在401（未授权）回应消息中。该域值由一个以上的
challenge组成，这些challenge可用于指出请求URI的授权方案及参数。

WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge

HTTP访问授权处理在11节中描述。用户代理在解析WWW-授权域值时要特别注意看
看它是否包含一个以上的待解决问题（challenge）或是否提供了一个以上的WWW-授权标
题域，因为待解决问题（challenge）的内容中可能包含用逗号分隔的授权参数列表。


11.  访问鉴别（Access Authentication）

	HTTP提供了一个简单的质询回应（challenge-response）鉴别机制，可用于服务器通过
客户端提供的授权信息来对其进行身份鉴别。授权方案用可扩展的、大小写敏感的符号来标
识，后跟获取证明所需要的以逗号分隔的‘属性－值’对。

auth-scheme    = token

auth-param     = token "=" quoted-string

	原始服务器用401（未授权）回应消息来质询用户代理的授权。该回应必须包括WWW-
授权标题域，而该WWW-授权标题域包括一个以上用于请求资源认证的参数（challenge）。

challenge		= auth-scheme 1*SP realm *( "," auth-param )

realm		= "realm" "=" realm-value
realm-value	= quoted-string

	凡涉及到参数（challenge）处理的授权方案都有realm属性（大小写敏感）。与标准URL
（相对于被访问服务器root）联合使用的realm值（也是大小写敏感）用来定义保护区域。
Realm使得服务器上的被保护资源被放在特殊的保护分区内，这些区域都有各自的授权方案
和（或）授权数据库。Relm值是个字符串，通常由原始服务器来分配，对于授权方案来说，
可能存在些附加的语法处理问题。
	通常，用户代理在收到401（未授权）回应时，可能（也可能不会）希望服务器对其授
权。如果希望授权，用户代理将在请求中加入授权请求标题（Authorization request-header）
域。授权域值由信任证书组成，其中有对用户代理所请求资源领域的授权信息。

credentials    = basic-credentials
                      | ( auth-scheme #auth-param )
	
	可由用户代理通过信任方式来访问的区域由保护区域决定。如果早先的请求已经通过认
证，在由授权方案，参数和（或）用户选择等所指定的时间间隔内，其它的请求可通过相同
的信任来访问该保护区域。

	除非由授权另行指定，否则单个保护区域的范围不能扩展到服务器之外。
	
	如果服务器不希望通过请求来接受信任，它应当返回403（禁止）回应。

	HTTP协议的访问授权不限于这种简单的质询回应（challenge-response）机制，还可以
使用其它的方法，比如传输级加密或消息封装及通过附加标题域来指定授权信息等等。但是，
这些方法不在本文档的讨论范围。
	
	代理必须完全透明地处理用户授权，也就是说，它们必须在不做任何改动的前提下将
WWW-授权及授权标题向前推送，也不可以对包含授权的回应进行缓存。HTTP/1.0不为客
户端提供通过代理方式授权的方法。

11.1  基本授权方案（Basic Authentication Scheme）
	
	用户代理必须对于每个领域（realm）通过用户标识（user-ID）及口令来对自身进行授
权，这是基本授权方案的工作模式。Realm值应当被看作不透明的字符串，该值将用于同服
务器端其它的realm值相比较。只有用户标识及口令通过受保护资源的认证，服务器才会给
请求授权。授权参数没有可选项。
	
	在接收到对受保护区域的未经认证的资源请求时，服务器应当回应一个质询
（challenge），如下：

WWW-Authenticate: Basic realm="WallyWorld"

"WallyWorld"是由服务器分配的字符串，用于对请求URI所指定的受保护资源进行标
识。
	
	为了接收授权，客户端需要在基于64位（base64 [5]）的证书中发送用户标识及口令，
中间用冒号':'分隔。

basic-credentials = "Basic" SP basic-cookie

basic-cookie      = <base64 [5] encoding of userid-password,
                            except not limited to 76 char/line>

userid-password   = [ token ] ":" *TEXT
	
	如果用户代理希望发送用户标识"Aladdin"和口令“open sesame”，应当遵循下面的标题
域形式：

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

	Basic授权方案是对HTTP服务器资源的非授权访问进行过滤的非安全方法。它基于假
定客户端与服务器端的连接是安全的，为什么说是假定呢，因为在实际的开放性网络中，使
用basic授权方案往往存在许多不安全的地方。尽管如此，客户端仍然需要实现此方案，以
与采用此种方案的服务器进行通讯。

12.  安全考虑（Security Considerations）

	本节的描述对下面各角色有关：信息应用开发者、信息提供者、HTTP/1.0中受安全性
限制的用户。本节仅是讨论安全问题，并对减少隐患提出了建议，但是并不提供对问题的最
终解决办法。

12.1  客户授权（Authentication of Clients）

	正如11.1节中所述，基本授权（Basic authentication）方案不是安全的用户授权方案，
也不能用它来防止实体主体源码以文本方式在物理网络中传输。HTTP/1.0并不反对在目前
日益突出的安全问题面前采用其它的授权方式及加密机制。

12.2  安全方法（Safe Methods）

	客户端软件开发者应当注意，客户端软件代表用户在Internet上与其它方面交互，并应
注意避免让用户知道其间发生的具体动作，这些动作可能会暴露对交互各方有重要意义的信
息。

	特别情况下，按协定来看，GET和HEAD方法应被视作是安全的，同重新获得数据应
当没有什么不同。这就允许用户代理采用其它方法，如POST，在某种情况下，可能存在这
样一种情况，即请求中包含不安全的行为。

	通常，服务器端在执行过GET请求之后，其结果之类的副产品还残留在服务器上；实
际上，一些动态资源需要这种特性来实现。这里的重要区别在于用户没有请求这些副产品，
因而也不应当对这类请求进行解释。

12.3  服务器日志信息的弊端（Abuse of Server Log 
Information）

	服务器为保存与用户请求相关的个人数据，如阅读方式或感兴趣的主题等提供了空间。
这些存储信息显然是受某些国家法律保护的，所以对此类数据的处理应当小心。用HTTP
协议提供数据的一方应当负责保证这些信息在未得各方许可之前不会散布出去。

12.4  敏感信息传输（Transfer of Sensitive Information）

	与其它协议一样，HTTP协议不能调整传输数据的内容，也不存在未卜先知的方法，通
过给定请求的上下文信息片段就能推测出信息的敏感程度。因而，应用程序应当尽可能像信
息提供方一样，为该信息提供更多的控制。在此，有三个标题域值得一提：服务端（Server）、
提交方（Referer）和来自（From）。

	一些指定服务器软件的版本有启示作用，因为这些版本的软件存在一些安全漏洞，将使
服务器更易受到攻击。提倡服务器软件在实现时，将Server标题域变成可以进行配置的选
项。

	提交方（Referer）标题域允许阅读方式（reading patterns）被暴露，并可导出反向链接。
虽然该域很有用，但是如果包含在此域的用户信息如果没有被分开，则它的作用很可能被滥
用。另外，即使此域中用户信息被清除，从该域的其它信息仍可推测出其私有文件的URI，
这可能是该信息发布者所不想看到的。
	
	来自（From）标题域可能包括一些与用户私人隐私及站点安全相关的信息，因而，在
发送数据前，应当允许用户使用一些设定手段，如禁止（disable）、允许（enable）、及修改
（modify），对此域信息进行配置。用户应当能够根据他们的选择或使用应用程序提供的缺
省配置来设定此域的内容。

	我们建议，但不做要求：为用户提供方便的界面来允许（enable）或禁止（disable）发
送From域或Referer域的信息。


12.5  基于文件及路径名的攻击（Attacks Based On File and 
Path Names）

	HTTP原始服务器的实现应当注意，要对以服务器管理员名义发出的，对某个文件的
HTTP请求进行限制。如果HTTP服务器直接将HTTP URI发送给系统调用，服务器要特别
注意，当某个请求文件不是发往HTTP客户端时，要予以拒绝服务。例如，在Unix、Microsoft 
Windows以及其它的操作系统使用".."做为上级目录名。在这样的系统下，HTTP服务器端
必须禁止通过使用这种结构的请求URI来访问HTTP服务器其它范围的资源。同样，服务
器端内部使用的一些文件，包括访问控制文件，配置文件、script代码等，也要受到特别保
护，以避免被非法请求获取，导致系统敏感信息暴露。实验证明，哪怕是最小的bug，也可
能导致严重的安全问题。

13.  感谢（Acknowledgments）

	本文档着重论述补充反馈方式（augmented BNF）及由David H. Crocker在RFC822[7]
中定义的一般结构。同样，它使用了许多由Nathaniel Borenstein和Ned Freed为MIME [5]
做的许多定义。我们希望通过它们来减少对HTTP/1.0及mail消息格式之间关系的混淆。
	HTTP协议在过去四年中发展很快，它得益于庞大而活跃的开发团体――是他们，这些
参与WWW讨论邮件列表的人们，造就了HTTP在全球范围内的成功。Marc Andreessen，
Robert Cailliau， Daniel W. Connolly，Bob Denny，Jean-Francois Groff， Phillip M. 
Hallam-Baker， Hakon W. Lie， Ari Luotonen，Rob McCool， Lou   Montulli， Dave Raggett，
Tony Sanders，和Marc VanHeyningen，他们为本文档早期版本投入了巨大精力。Paul Hoffman
提供了关于信息状态方面的信息，以及附录C、D的内容。

	该文档从HTTP-WG成员的评注中得益非浅。以下是对本规范做出贡献的人们：

Gary Adams						Harald Tveit Alvestrand
Keith Ball						Brian Behlendorf
Paul Burchard						Maurizio Codogno
Mike Cowlishaw					Roman Czyborra
Michael A. Dolan					John Franks
Jim Gettys						Marc Hedlund
Koen Holtman						Alex Hopmann
Bob Jernigan						Shel Kaphan
Martijn Koster						Dave Kristol
Daniel LaLiberte					Paul Leach
Albert Lunde						John C. Mallery
Larry Masinter					Mitra
Jeffrey Mogul						Gavin Nicol
Bill Perry							Jeffrey Perry
Owen Rees						Luigi Rizzo
David Robinson					Marc Salomon
Rich Salz							Jim Seidman
Chuck Shotton						Eric W. Sink
Simon E. Spero					Robert S. Thau
Francois Yergeau					Mary Ellen Zurko
Jean-Philippe Martin-Flatin

14. 参考书目（References）

   [1]  Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
        Torrey, D., and B. Alberti, "The Internet Gopher Protocol: A
        Distributed Document Search and Retrieval Protocol", RFC 1436,
        University of Minnesota, March 1993.

   [2]  Berners-Lee, T., "Universal Resource Identifiers in WWW: A
        Unifying Syntax for the Expression of Names and Addresses of
        Objects on the Network as used in the World-Wide Web",
        RFC 1630, CERN, June 1994.

   [3]  Berners-Lee, T., and D. Connolly, "Hypertext Markup Language -
        2.0", RFC 1866, MIT/W3C, November 1995.

   [4]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
        Resource Locators (URL)", RFC 1738, CERN, Xerox PARC,
        University of Minnesota, December 1994.

   [5]  Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
        Extensions) Part One: Mechanisms for Specifying and Describing
        the Format of Internet Message Bodies", RFC 1521, Bellcore,
        Innosoft, September 1993.
   [6]  Braden, R., "Requirements for Internet hosts - Application and
        Support", STD 3, RFC 1123, IETF, October 1989.
   [7]  Crocker, D., "Standard for the Format of ARPA Internet Text
        Messages", STD 11, RFC 822, UDEL, August 1982.
   [8]  F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang,
        J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype
        Functional Specification." (v1.5), Thinking Machines
        Corporation, April 1990.
   [9]  Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
        UC Irvine, June 1995.
   [10] Horton, M., and R. Adams, "Standard for interchange of USENET
        Messages", RFC 1036 (Obsoletes RFC 850), AT&T Bell
        Laboratories, Center for Seismic Studies, December 1987.
   [11] Kantor, B., and P. Lapsley, "Network News Transfer Protocol:
        A Proposed Standard for the Stream-Based Transmission of News",
        RFC 977, UC San Diego, UC Berkeley, February 1986.
   [12] Postel, J., "Simple Mail Transfer Protocol." STD 10, RFC 821,
        USC/ISI, August 1982.
   [13] Postel, J., "Media Type Registration Procedure." RFC 1590,
        USC/ISI, March 1994.
   [14] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
        STD 9, RFC 959, USC/ISI, October 1985.
   [15] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
        1700, USC/ISI, October 1994.
   [16] Sollins, K., and L. Masinter, "Functional Requirements for
        Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,
        December 1994.
   [17] US-ASCII. Coded Character Set - 7-Bit American Standard Code
        for Information Interchange. Standard ANSI X3.4-1986, ANSI,
        1986.
   [18] ISO-8859. International Standard -- Information Processing --
        8-bit Single-Byte Coded Graphic Character Sets --
        Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
        Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
        Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.
        Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.
        Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
        Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
        Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
        Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
        Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.

15.  作者地址（Authors' Addresses）

   Tim Berners-Lee
   Director, W3 Consortium
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, U.S.A.

   Fax: +1 (617) 258 8682
   EMail: timbl@w3.org


   Roy T. Fielding
   Department of Information and Computer Science
   University of California
   Irvine, CA 92717-3425, U.S.A.

   Fax: +1 (714) 824-4056
   EMail: fielding@ics.uci.edu


   Henrik Frystyk Nielsen
   W3 Consortium
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, U.S.A.

   Fax: +1 (617) 258 8682
   EMail: frystyk@w3.org

附录（Appendices）
	这些信息出现在附录中仅有一个理由，即他们没有成为HTTP/1.0规范的组成部分。

A.  Internet介质类型消息/http（Internet Media Type 
message/http）

	做为HTTP/1.0协议的补充，该文档做为Internet介质类型"message/http"的规范。下面
内容被登记在IANA[13]中。

介质类型名（Media Type name）：			message

介质子类型名（Media subtype name）：		http

请求参数（Required parameters）：			none

可选参数项（Optional parameters）：			version, msgtype

版本（version）：附加消息的HTTP版本号，比如“1.0”。如果没有给出，版
本可以从其主体的第一行中得到。
			
消息类型（msgtype）：消息类型――请求（request）或回应（response）。如果
没有给出，版本可以从其主体的第一行中得到。

编码考虑（Encoding considerations）：只允许用"7bit", "8bit",或"binary" 。

安全考虑（Security considerations）： none

B.  容错应用（Tolerant Applications）

	虽然此文档指明了产生HTTP/1.0消息的必要条件，并非所有的应用程序都校正他们的
实现。因此，我们建议应用程序增强其容错能力，以便在岐义仍可被明确解释时，还能保证
正常运行。
	客户端解析状态行（Status-Line）及服务器解析请求行（Request-Line）时，应当做到容
错。特别是，即使只需要一个SP分隔的情况下，它们也可接受以任何数量的SP或HT字
符分隔的域。
	HTTP标题域的行终止符是顺序字符CRLF。而我们建议应用程序在解析这类标题时，
也应识别单个LF（没有前面的CR）做为终止符情况。

C.  与MIME的关系（Relationship to MIME）

	HTTP/1.0使用了许多为Internet Mail（RFC822[7]）及多用途Internet邮件扩展
（Multipurpose Internet Mail Extensions）MIME[5]定义的结构，以允许实体通过一种开放的
可扩展的机制进行传输。实际上，HTTP中有些特性与RFC1521中讨论的邮件不同，这些
区别被用来优化二进制传输的性能，给介质类型的使用提供了更大的自由度，使日期比较变
得更加容易，当然，这也是为了兼容早期的一些HTTP服务器及客户端的应用。

	在写作本文时，据说RFC1521将被修订。修订版本将会包括一些出现在HTTP/1.0中的
已有的应用，但这些应用在目前的RFC1521中尚未包括。
	
	该附录描述了HTTP与RFC1521中的不同之处。代理和网关在限制MIME环境时，应
当注意到这些区别，并在必须时提供相应的转换支持。从MIME到HTTP环境的代理和网
关也要注意这些区别，因为一些转换可能是必须的。

C.1  转换为规范形式（Conversion to Canonical Form）

	RFC1521要求Internet邮件实体在被传输前转换成规范形式，正如RFC1521[5]附录C
中所描述的那样。本文档中3.6.1节中描述了HTTP在传输时允许的“text”介质类型的子类
型的具体形式。
	
	RFC1521要求"text"的内容类型（Content-Type）必须用CRLF作为行中断符，禁止单独
使用CR或LF。HTTP允许在HTTP传输时使用CRLF、单独的CR或LF做为行中断符。
	
	只要有可能，HTTP环境或RFC1521环境下的代理或网关应当将本文档3.6.1节中描述
的文本介质类型中的所有行中断符都转换成CRLF。注意，由于存在着内容编码
（Content-Encoding）问题，以及HTTP允许使用多字符集，而其中的某些字符集不用字节
13和10做为CR和LF，这样就使实际的处理更加复杂。

C.2  日期格式转换（Conversion of Date Formats）

	HTTP/1.0使用受限制的日期格式集（3.3节）以简化日期比较的处理。其它协议的代理
和网关应当保证消息中的任何日期标题域与HTTP/1.0格式一致，否则，要对其进行改写。

C.3  内容编码介绍（Introduction of Content-Encoding）

	RFC1521不包括殊如HTTP/1.0中内容编码标题域之类的概念。由于内容类型域是介质
类型的修饰，因而从HTTP到MIME兼容协议中的代理和网关必须在将消息向前推送之前，
更改内容类型标题域（Content-Type）的值或者对实体主体（Entity-Body）进行解码（有些
Internet mail内容类型的实验性应用采用介质类型参数为";conversions=<content-coding>"来
替代内容解码，而事实上，该参数并非RFC1521的组成部分）。

C.4  无内容传输编码（No Content-Transfer-Encoding）

	HTTP不使用RFC1521的CTE（Content-Transfer-Encoding）域。与MIME协议兼容的
代理和网关在向HTTP客户端传递回应消息前都必须清除任何无标识的CTE编码
（"quoted-printable"或"base64"）。
	
	从HTTP到MIME兼容协议的代理和网关要负责保证协议上消息格式正确及编码传输
安全，所谓安全传输是指满足对应协议所规定的限制或约束标准。代理或网关应当用适当的
内容传输编码（Content-Transfer-Encoding）来标识数据，以提高在目的协议上实现安全传输
的可能性。

C.5  多个主体的HTTP标题域（HTTP Header Fields in 
Multipart Body-Parts）

	在RFC1521中，大多数多个主体组成的标题域通常会被忽略，除非其域名以"Content-"开
头。在HTTP/1.0中，多个主体部分（multipart body-parts）所包含的任何HTTP标题域，只
对对应的部分有意义。

D.  附加特性（Additional Features）

	该附录中包括的一些协议元素存在于一些HTTP实现中，但并非对所有的HTTP/1.0的
应用都适用。开发者应注意这些特性，但不能依赖它们来与其它的HTTP/1.0应用程序进行
交互。

D.1  附加请求方法（Additional Request Methods）

D.1.1 PUT

	PUT方法请求服务器将附件的实体储存在提供的请求URI处。如果该请求URI指向的
资源已经存在，则附件实体应被看做是当前原始服务器上资源的修改版本。如果请求URI
没有指向现存的资源，该URI将被该请求的用户代理定义成为一个新的资源，原始服务器
将用该URI产生这个资源。
	
	POST与PUT两种请求的基本区别在于对请求URI的理解不同。在POST请求方法中
的URI所标识的资源将做为附件实体被服务器处理，该资源可能是数据接收处理过程、某
些其它协议的网关、或可被注释的单独实体。与此相反，用户代理很清楚它发出的PUT请
求中附带URI所标识的实体指向何处，而服务器处不应将该请求用到其它资源头上。 

D.1.2 DELETE
	
	DELETE方法请求原始服务器删除由请求URI所指定的资源。

D.1.3 LINK

	LINK方法建立与请求URI所指定资源或其它已存在资源之间的一个或多个连接关系。

D.1.4 UNLINK
	
	UNLINK方法删除与请求URI所指定资源之间的一个或多个连接关系。

D.2  附加标题域定义（Additional Header Field Definitions）

D.2.1 Accept

	Accept请求标题域用于指示可被接受的请求回应的介质范围列表。星号"*"用于按范围
将介质类型分组，用"*/*"指示可接受全部介质类型；用"type/*"指示可接受type类型的所有
子类型。对于给定请求的上下文，客户端应当表示出哪些类型是它可以接受的。

D.2.2 可接受的字体集（Accept-Charset）

	Accept-Charset请求标题域用来指示除了US-ASCII和ISO-8859-1外，首选的字符集。
该域将使客户端有能力理解更广泛的或有特殊用途的字符集，从而在服务器上可以存放采用
此类字符集的文档。

D.2.3 可接受编码（Accept-Encoding）

	Accept-Encoding请求标题域与Accept相似，但是限制了回应中可接受的内容编码
（content-coding）值。

D.2.4 可接受语言（Accept-Language）

	Accept-Language请求标题域与Accept相似，但限制了请求回应中首选的自然语言集。

D.2.5 内容语言（Content-Language）

	Content-Language实体标题域描述了附加实体中为听众指定的自然语言。注意，这可能
与在实体内部使用的各种语言不是一码事。

D.2.6 连接（Link）

	Link实体标题域描述了实体和某些其它资源之间的关系。一个实体可能包括多个连接
值。处于元信息级的Link指明了分层结构和导航路径之间的关系。

D.2.7 MIME版本（MIME-Version）

	HTTP消息可能包括一个单独的MIME版本的普通标题（general-header）域，用以指示
用来构造消息的MIME协议的版本。MIME版本标题域的使用，正如RFC1521[5]中定义的
那样，应当用来指示消息是否符合MIME规范。然而不幸的是，一些老的HTTP/1.0服务器
不加选择地发送此域，导致此域已经被废弃。

D.2.8 在….后重试（Retry-After）

	Retry-After回应标题域可与503（服务不可用）回应一起使用，用于指示服务器停止响
应客户请求的时间长短。该域的值可用HTTP格式的日期表示，也可以用整数来表示回应时
间后的秒数。

D.2.9 标题（Title）

	Title实体标题域用于指示实体的标题。

D.2.10 URI

	URI实体标题域可能包含一些或全部统一资源标识（Uniform Resource Identifiers），见
3.2节，通过这些标识来表示请求URI所指定的资源。并不担保根据URI一定能够找到指定
的资源。

RFC1945——Hyptertext Transfer Protocol – HTTP/1.0                  超文本传输协议1.0


1
RFC文档中文翻译计划