rfc1945.htm

RFC文档

                      | "May" | "Jun" | "Jul" | "Aug"
                      | "Sep" | "Oct" | "Nov" | "Dec"
注意：HTTP要求只能在协议流中使用data/time时间戳格式，不要求客户端及服务
器端在用户描述、请求登录等情况下使用这类格式。
3.4  字符集（Character Sets）

	HTTP所使用的字符集定义和描述MIME时用的相同：
本文档用字符集（character set）来指明利用一个或多个表将顺序字节转换成顺序字
符的方法。注意，不需要其它方向的无条件转换，因为不是所有的字符都可以用给
定字符集来表示，同时，一个字符集也可能提供一种以上的字节顺序来表示一种特
殊的字符。这种定义倾向于允许不同类型的字符编码通过简单的单表映射来实现，
如，从表US-ASCII切换到复杂表如ISO2202。实际上，与MIME字符集名相关的
定义必须完整指定从字节到字符的映射，特别是不允许通过利用外部配置信息来确
定精确的映射。

注意：术语字符集（character set）归于字符编码（character encoding）。事实上，
由于HTTP与MIME共同使用同样的注册，所以其术语也应一致。
		
HTTP字符集由大小写敏感的符号组成。全部的符号定义参见IANA字符集注册
[15]。因为注册处不会为每个字符集单独定义一套符号，所以我们在这看到的字符
集名大多是与HTTP实体使用相关的。这些在RFC 1521 [5] 中注册的字符集，即
US-ASCII [17] 及ISO-8859 [18]字符集，还有一些其它字符集被强烈建议在MIME
字符集参数内部使用。

charset = "US-ASCII"
             | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
             | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
             | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
             | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
             | "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"
             | token
		
虽然HTTP允许使用专用符号做为字符集值，但是任何在IANA字符集注册表[15]
中有预定义值的符号都必须表明其所属的字符集。应用应当将其对字符集的使用限
制在IANA注册表规定的范围之内。

实体主体的字符集如果属于US-ASCII 或ISO-8859-1字符集，则勿需标记，否则，
应当用主体字符编码方式中的最基本命名来标记。

3.5  内容译码（Content Codings）
	内容译码值用于指示对资源进行的编码转换。内容译码主要用于将经过压缩、加密等操
作的文件进行还原，使其保持其原来的介质类型。典型情况下，经过编码保存的资源只能经
过解码或类似的操作才能还原。
content-coding = "x-gzip" | "x-compress" | token
	注意：出于对未来兼容性的考虑，HTTP/1.0应用应将"gzip" 和"compress" 分别与 
"x-gzip"和"x-compress"对应起来。
	所有的内容译码值都是大小写敏感的。HTTP/1.0在内容编码（10.3节）头域中使用内
容译码值。虽然该值描述的是内容译码，但更为重要的是，它指明了应当用什么机制来进行
解码。注意，单独的程序可能有能力实现对多种格式编码的解码。
	在这段文字中，提到了两个值：
x-gzip
文件压缩程序"gzip" (GNU zip，由Jean-loup Gailly开发)的编码格式。该格式属于
典型的带有32位CRC 校验的Lempel-Ziv译码 (LZ77)。
x-compress
文件压缩程序"compress"的编码格式，该格式适用于LZW（Lempel-Ziv-Welch）译
码。
注意：用程序名来标识编码格式的做法不是很理想，在将来可能不会继续这样做。现在
之所以这样做是出于历史的原因，并非良好的设计。

3.6  介质类型（Media Types）

	HTTP在Content-Type header域（10.5节）中使用Internet介质类型[13]，用以提供开放
的可扩展的数据类型。
media-type		= type "/" subtype *( ";" parameter )
type				= token
subtype			= token

	参数可参照属性/值对的方式，用类型/子类型的格式来写。

Parameter		= attribute "=" value
Attribute			= token
Value			= token | quoted-string

	其中，类型、子类型、参数属性名是大小写敏感的。而参数值不一定是大小写敏感的，
这得看参数名的语法而定。在类型和子类型、属性名和属性值之间不能有LWS（空格）。当
接收到不能识别的介质类型的参数时，用户代理应当忽略它们。
	一些老的HTTP应用不能识别介质类型参数，所以HTTP/1.0的应用程序只能在定义消
息内容时使用介质参数。
	介质参数（Media-type）值用Internet授权分配数字（Internet Assigned Number   
Authority ，IANA [15]）注册。介质类型注册过程请参见RFC1590[13]。不鼓励使用未注册
的介质类型。

3.6.1标准及文本缺省（Canonicalization and Text Defaults）
	Internet介质类型是用规范形式注册的。一般来说，在通过HTTP协议传输实体主体
（Entity-Body）之前，必须先将其表示成适当的规范格式。如果主体用使用了一种
Content-Encoding进行编码，下面的数据在编码前必须转换成规范形式：
	"text"类型的介质子类型在规范形式中使用CRLF做为文本行中断。实际上，为和实体
主体（Entity body）内的使用方式保持一致，HTTP允许传输纯以CR或LF单独表示行中断
的文本介质。HTTP应用程序必须将其通过HTTP方式接收到的文本介质中的CRLF、CR、
LF看做是行中断符。

	另外，如果文本介质的字符集没有使用字节13和10做为CR和LF，象一些多字节字
符集，HTTP允许使用该字符集指定的任何顺序的字节替代CR和LF做为行中断，这种行
中断的灵活运用方式仅可于实体主体（Entity-Body）中。一个纯CR或LF不应在任何HTTP
控制结构（如标题域-header field和多块分界线-multipart boundaries）中替代CRLF。
	参数"charset"在定义数据的字符集（3.4节）时，与一些介质类型一起使用。当发送方
没有显式给出字符参数时，HTTP在接收时将"text"的介质子类型定义为缺省
值"ISO-8859-1"。"ISO-8859-1"字符集或其子集以外的数据必须要标记其相应的字符集值，
这样可以保证接收方能正确地对其进行解析。
	注意：许多当前HTTP服务器提供的数据使用"ISO-8859-1"以外的其它字符集，而且也
没有正确的进行标记，这种工作方式限制了互操作性，建议不要采用。做为一种补救方法，
一些HTTP用户代理提供了配置选项，使用户可以在字符集参数没指定的情况下，自行更改
缺省的介质类型解释方式。

3.6.2 多部分类型（Multipart Types）


	MIME提供了多部分（"multipart"）类型的数字――在一个单独的消息实体主体
（Entity-Body）内可以封装几个实体（entities）。虽然用户代理可能需要了解每种类型，从
而可以正确解释每部分主体的意图，但是在IANA[15]的多部分类型（multipart types）注册
中却找不到专为HTTP/1.0所指定的内容。HTTP用户代理只得自己来做接收多部分类型的
工作，其过程和行为与MIME用户代理是相同或相似的。HTTP服务器不应假定HTTP客户
端都有能力处理多部分类型。
	
	所有的多部分类型都使用通用的语法，而且必须在介质类型值部分包括边界参数
（boundary parameter）。消息的主体是其自身，做为协议元素，它必须只使用CRLF做为段
间（body-parts）的行中断符。多段主体（Multipart body-parts）中可能包括对各段有重要意
义的HTTP标题域。

3.7  产品标识（Product Tokens）
	是通讯应用程序用来标识其自身的一个简单符号，常和任意字母及版本描述一起使用。
大多数产品标识也将其产品的重要组成部分的版本号一起列出，中间用空格分隔。

	按惯例，在标识应用程序时，组件以其重要性顺序排列。
Product			= token ["/" product-version]
product-version 	= token
例如：
       User-Agent: CERN-LineMode/2.15 libwww/2.17b3
       Server: Apache/0.8.4
	产品标识应当短小，因而禁止利用该域填写广告或其它无关信息。虽然任何符号字符都
可能出现在产品版本中，该符号应当只用于做版本定义，也就是说，同一个产品的连续版本
之间只能通过产品版本值进行区分。

4.  HTTP 消息（HTTP Message）

4.1  消息类型（Message Types）
	
	HTTP消息由客户端到服务器的请求和由服务器到客户端的回应组成。

HTTP-message   = Simple-Request			; HTTP/0.9 messages
                      | Simple-Response
                      | Full-Request				; HTTP/1.0 messages
                      | Full-Response

	完整的请求（Full-Request）和完整的回应（Full-Response）都使用RFC822[7]中实体传
输部分规定的消息格式。两者的消息都可能包括标题域（headers，可选）、实体主体（entity 
body）。实体主体与标题间通过空行来分隔（即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

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
	
	简单请求（Simple_Request）与简单回应（Simple-Response）不允许使用任何标题信息，
并限制只能使用唯一的请求方法（GET）

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

       Simple-Response = [ Entity-Body ]
	不提倡使用简单方式请求格式，因为它防止了服务器在接到简单请求时对返回实体的介
质类型进行验证。


4.2  消息标题（Message Headers）
	HTTP标题域，包括主标题（General-Header,4.3节）、请求标题（Request-Header ,5.2节）、
回应标题（Response-Header ,6.2节）及实体标题（Entity-Header,7.1节），都遵照RFC822-3.1
节[7]给出的通用格式定义。每个标题域由后紧跟冒号的名字，单空格（SP），字符及域值组
成。域名是大小写敏感的。虽然不提倡，标题域还是可以扩展成多行使用，只要这些行以一
个以上的SP或HT开头就行。

HTTP-header		= field-name ":" [ field-value ] CRLF

field-name		= token
field-value		= *( field-content | LWS )

field-content		= <the OCTETs making up the field-value
                        and consisting of either *TEXT or combinations
                        of token, tspecials, and quoted-string>
标题域接收的顺序并不重要，但良好的习惯是，先发送主标题，然后是请求标题或回应
标题，最后是实体标题。
	当且仅当标题域的全部域值都用逗号分隔的列表示时（即，#（值）），多个有相同域名
的HTTP标题域才可以表示在一个消息里。而且必须能在不改变消息语法的前提下，将并发
的域值加到第一个值后面，之间用逗号分隔，最终能将多个标题域结合成“域名：域值”对。

4.3  普通标题域（General Header Fields）
	
	有几种标题域是请求与回应都要使用的，但并不用于被传输的实体。这些标题只用于被
传输的消息。

General-Header = Date			; Section 10.6
                      | Pragma		; Section 10.12
	普通标题域名称只有在与协议版本的变化结合起来后，才能进行可靠的扩展。实际上，
新的或实验中的标题域只要能被通讯各方识别，其语法就可使用，而无法识别的标题域都将
被视为实体域。

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连接，并在完整请求之
后发送下面的命令：