精华区 [关闭][返回]

当前位置:网易精华区>>讨论区精华>>网络专区>>● Network>>● TCPIP>>RFC2068-HTTP/1.1(10)

主题:RFC2068-HTTP/1.1(10)
发信人: 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]

[关闭][返回]