[讨论] 规范中关于HTTP Header的章节，是一个很好的需求规范，可以开发一个Header分析程序
178 views
Skip to first unread message
靳雄飞
Nov 22, 2009, 10:46:22 PM11/22/09
to dus...@googlegroups.com
HTTP协议规范4.2关于消息头的描述，有如下几个关键点：
1、header field的内容不包括前导或者后缀的LWS
2、不同名字的header field的顺序无关
3、同名header field可以多次出现，但内容被当作列表对待，且与出现顺序有关
4、header field的名字（name）和值（value）之间用冒号“:”分割
5、header field的名字（name）是不区分大小写的
6、当一个header field的值域跨行时，后续行必须以空白字符开头（这就意味着，header field的name之前不能有空白字符）
原来不是有好多朋友想做一些实战开发吗？
这就是一个很好的需求，大家可以写一个简单的HTTP 消息分析程序。
4.2 Message Headers
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 consists
of a name followed by a colon (":") and the field value. Field names
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 ought to follow "common form", where
one is known or indicated, when generating HTTP constructs, since
there might exist some implementations that fail to accept anything
beyond the common forms.
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>
The field-content does not include any leading or trailing LWS:
linear white space occurring before the first non-whitespace
character of the field-value or after the last non-whitespace
character of the field-value. Such leading or trailing LWS MAY be
removed without changing the semantics of the field value. Any LWS
that occurs between field-content MAY be replaced with a single SP
before interpreting the field value or forwarding the message
downstream.
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 the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST NOT
change the order of these field values when a message is forwarded.
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 consists
of a name followed by a colon (":") and the field value. Field names
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 ought to follow "common form", where
one is known or indicated, when generating HTTP constructs, since
there might exist some implementations that fail to accept anything
beyond the common forms.
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>
The field-content does not include any leading or trailing LWS:
linear white space occurring before the first non-whitespace
character of the field-value or after the last non-whitespace
character of the field-value. Such leading or trailing LWS MAY be
removed without changing the semantics of the field value. Any LWS
that occurs between field-content MAY be replaced with a single SP
before interpreting the field value or forwarding the message
downstream.
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 the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST NOT
change the order of these field values when a message is forwarded.
任水
Nov 22, 2009, 10:51:16 PM11/22/09
to dus...@googlegroups.com
规范要表达的意思应该是：heade-value的前后可以包括LWS，但这些LWS毫无意义，消息接收方不会理会这些LWS.
==========
1、header field的内容不包括前导或者后缀的LWS
发件人: dus...@googlegroups.com
[mailto:dus...@googlegroups.com] 代表 靳雄飞
发送时间: 2009年11月23日星期一 11:46
收件人:
dus...@googlegroups.com
主题: [dusplan] [讨论] 规范中关于HTTP Header的章节，是一个很好的需求规范，可以开发一个Header分析程序
靳雄飞
Nov 22, 2009, 11:00:32 PM11/22/09
to dus...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages