HTTP1.1翻译<4>

Posted on 2005-09-21 21:21 英雄 阅读(1481) 评论(0)  编辑  收藏 所属分类: HTTP1.1协议中文翻译

4.HTTP 消息

41消息类型

HTTP消息由客户端发到服务器端的request和相反方向的response组成。

HTTP-message = Request | Response ; HTTP/1.1 messages

Request(sec5)response(sec6)消息使用RFC822[9]的通用消息格式来传递实体(message的有效负荷)。由一个开始行,0或多个头区(头部),一个空行(在CRLF前什么也没有)来指示头区结束,和一个可能的body

generic-message = start-line

*(message-header CRLF)

CRLF

[ message-body ]

start-line = Request-Line | Status-Line

为了保持健壮性,服务器应该在Request-Line被期待的地方忽略任何空行。换句话说,如果服务器在消息的开始读协议流,首先接收了一个CRLF,它应该忽略crlf

某些臭虫很多的HTTP/10client实现产生额外的CRLF在一个POSTrequest后。重申一下在 BNF处的禁令,一个HTTP/11client绝对不能在一个request的前后加CRLF

42消息头

HTTP头区,包含general-header (section 4.5), request-header (section 5.3), response-header

(section 6.2), entity-header (section 7.1) fields,遵从通用的格式定义(sec3.1RFC822[9])。每一个头区由一个名字跟着一个:和一个区值组成。区名是大小写不敏感的。区值可以一任何数目的LWS开头,虽然一个SP最好。头区可以扩展成多行,当然需要使用最少一个SPHT来作为多出行的引导。应用应该遵从都知道的或被指明的通用形式来产生HTTP结构,因为可能出现某些应用无法接受超出通用形式的东西。

message-header = field-name ":" [ field-value ]

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, separators, and quoted-string>

field-content并没有包含任何打头的或结尾的LWS:出现在非空格字符前或后。而这样出现的LWS可以在不改变区值语义的情况下被删除掉。任何出现在field-content之间的LWS可以在解释区值或转向消息流前以SP取代之。

不同区名的头区出现顺序不相同也没有关系。但是,最好首先发送通用头区,然后是requestresponse头区,以entity-header头区结束。

在一个消息中可以出现多头区对应同一个区名,只要对那个头区的头区值是可以用逗号分隔的列表。必须可能把多个头区合并成“name:value”对而不改变语义。顺序是重要的,因为解释需要顺序,而且因此一个proxy绝对不能改变顺序。

43消息体

HTTP消息的消息体被用来携带跟随requestresponse的实体。消息体只在一个传输编码被使用时才和实体不同。

message-body = entity-body

| <entity-body encoded as per Transfer-Encoding>

当要保证消息被安全和合适传输时需要传输编码,Transfer-Encoding就是用来指示传输编码的。这是消息的一个属性,而不是实体的,因此可以在request/response链中被增加或删除。(但是,sec3.6增加了什么时候可以用这个属性)。

什么情况下确定消息中有一个消息体在requestresponse不同的。

Request是当包含Content-Length Transfer-Encoding头区时有消息体。如果一个 request的方法定义中不允许一个消息体包含在消息中发送,那么就绝对不能。一个server应该读或传递一个消息中的消息体,而如果request中的方法定义中没有指示消息体,那就应该忽略过去。

对于response,有无则依赖于request的方法和response的状态码(sec6.1.1)。所有对应HEADrequest 方法的肯定没有,即使实体头区的存在可能让人相信它存在。所有的1xx,204304也肯定没有。所有其它的一定有,即使它可能是0长度。

44消息长度

消息长度是指在传输编码使用后消息体的长度。当一个消息体被包含在一个消息中时,体长由下面决定(按优先级的顺序):

1.   任何肯定不包含一个消息体的response消息总是在第一个空行处终结,而无论出现在消息中的实体的头区。

2.   如果一个Transfer-Encoding头区(sec14.41)被给出而且只有”identity”,那么传输长度是使用“chunked”传输编码,直到连接被关闭消息被终结。

3.  如果一个Content-Length头区(sec14.13)被给出,那么它既代表了实体长度也代表了传输长度。如果这两个长度不相等肯定不会有Content-Length。如果一个消息既存在Transfer-Encoding又存在Content-Length,后者被忽略。

4.如果消息使用“multipart/byteranges”做媒体类型,并且transfer-length也没被给出,那么这个自定界的媒体类型定义了传输长度。这个类型如果接收者无法解析它那肯定不能被使用;在一个request中,如果包含一个Range头和若干byte-range说明那个client能够解析multipart/ranges。一个rang头可能被一个不理解multipart/byterangesproxy传递,在这种情况下,server必须使用135提供的方法定界。

5.到server关闭一个连接(关闭连接不能被用来指示一个request的结束,因为那样将导致server无法发送一个response。)

为了和HTTP/10应用兼容,包含一个消息体的。1请求肯定包含一个有效的Content-Length

除非知道serverHTTP/11兼容。如果一个request包含一个消息体而没有

Content-Length,那么server如果不能决定消息的长度应该回以400,或411如果它坚持接收一个有效Content-Length

所有接收实体的HTTP/11应用必须接收“chunked”传输编码(sec3.6),因此允许使用这个机制决定消息长度。

消息绝对不能同时包含Content-Length头区和一个非identity传输编码。如果一定包含,那么Content-Length被忽略。

如果一个Content-Length真被给出了,那 它一定对应消息体的字节个数。HTTP/11user agent必须告诉用户如果一个无效长度被接受和看到。

45通用头区

有一些头区在requestresponse中通用,但是不能用于被传输的实体。这些头区只用于被传递的消息。

general-header = Cache-Control ; Section 14.9

| Connection ; Section 14.10

| Date ; Section 14.18

| Pragma ; Section 14.32

| Trailer ; Section 14.40

| Transfer-Encoding ; Section 14.41

| Upgrade ; Section 14.42

| Via ; Section 14.45

| Warning ; Section 14.46

通用头区的名字可以跟随一个改变的版本号而被扩展。但是,新的或实验的头区可以被给通用头区的语义如果通讯双方都认同。认不出的头区被认为是实体头区。

 


只有注册用户登录后才能发表评论。


网站导航: