发信人: kenmlee()
整理人: kenmlee(2000-07-08 16:49:11), 站内信件
|
4 HTTP Message
#4. HTTP消息 /#
4.1 Message Types
#4.1 消息类型 /#
HTTP messages consist of requests from client to server and respons
es
from server to client.
HTTP-message = Request | Response ; HTTP/1.1 messages
# HTTP消息由客户程序向服务器发出的请求和服务器程序向客户返回的响应组成
.
HTTP-message = Request | Response ; HTTP/1.1 消息 /#
Request (section 5) and Response (section 6) messages use the gener
ic
message format of RFC 822 [9] for transferring entities (the payloa
d
of the message). Both types of message consist of a start-line, one
or more header fields (also known as "headers"), an empty line (i.e
.,
a line with nothing preceding the CRLF) indicating the end of the
header fields, and an optional message-body.
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
# 请求消息(第5节)和响应消息(第6节)使用RFC 822[9]定义的传输实体(消息净
荷)的
一般消息格式.两种消息都由一个开始行,一个或多个头域(也称为"头部"),一
个空行
(即,一个CRLF前无其他字符的行)用于指出头域的结束,和一个可选的消息体.
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
/#
In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words,
if
the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF.
# 考虑鲁棒性,服务器应该忽略所有在接收请求行(Request-Line)时遇到的空行
.
换言之,如果服务器程序读取协议数据流时在消息开始首先接收到一个CRLF,它
可以忽略这个CRLF.
/#
Note: certain buggy HTTP/1.0 client implementations generate an
extra CRLF's after a POST request. To restate what is explicitly
forbidden by the BNF, an HTTP/1.1 client must not preface or foll
ow
a request with an extra CRLF.
# 注意:某些由bug的HTTP/1.0客户应用程序实现在POST请求后生成一个额外的
CRLF.
重申BNF显式禁止的行为,一个HTTP/1.1的客户程序必须不能在请求之前或之
后加入
一个额外的CRLF.
/#
4.2 Message Headers
#4.2 消息头部 /#
HTTP header fields, which include general-header (section 4.5),
request-header (section 5.3), response-header (section 6.2), and
entity-header (section 7.1) fields, follow the same generic format
as
that given in Section 3.1 of RFC 822 [9]. Each header field consist
s
of a name followed by a colon (":") and the field value. Field name
s
are case-insensitive. The field value may be preceded by any amount
of LWS, though a single SP is preferred. Header fields can be
extended over multiple lines by preceding each extra line with at
least one SP or HT. Applications SHOULD follow "common form" when
generating HTTP constructs, since there might exist some
implementations that fail to accept anything beyond the common form
s.
message-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 combinati
ons
of token, tspecials, and quoted-string>
# HTTP头域包括通用头部(第4.5节),请求头部(第5.3节),响应头部(第6.2节),和
实体头部(第7.1节),都遵循RFC 822[9]第3.1节的定义有相同的一般格式.每个
头域由一个名字后加一个冒号(":")和域值组成.域名是大小写敏感的,域值前
可
以由任意多的LWS,但最好是只用一个空格(SP).头域可以通过在下一行开头插
入
至少一个SP或HT来将头域扩展到多行.应用程序在生成HTTP结构时应该遵循"普
通
形式"规则,因为可能存在一些不能接受除普通形式外其他内容的应用实现.
message-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <*TEXT或token,tspecials和quoted-string组成
的八位字节(OCTETs)域值>
/#
The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response
-
header fields, and ending with the entity-header fields.
# 不同域名的头域的接收次序是无关紧要的,然而,首先发送通用头域,接着发送
请求
头域或响应头域,最后发送实体头域是好习惯.
/#
Multiple message-header fields with the same field-name may be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)]
.
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of t
he
message, by appending each subsequent field-value to the first, eac
h
separated by a comma. The order in which header fields with the sam
e
field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST N
OT
change the order of these field values when a message is forwarded.
# 相同域名的多个消息头域可能出现在消息中,这种情况发生在如果并且只有整
个该
头域的域值是用逗号分割列表定义的[例如,#(values)].它必须可能组合多个
头域
到一个"field-name: field-value"对中,而不改变消息语义,域值通过顺序添
加每
个域值到第一个域值号,每个域值间用逗号分开.因此具有相同域名的头域的接
受顺
序对解释组合起来的域值变得重要了,并且因此代理在提交消息时必须不能改
变这些
域值的顺序.
/#
--
※ 修改:．kenmlee 于 Jul 8 16:30:35 修改本文．[FROM: 61.140.188.222]
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 61.140.188.222]
|
|