本文详细解析了HTTP消息的构成，包括请求与响应消息的格式、头部字段和消息体的定义及使用规范。通过实例展示了HTTP/1.1交互过程。
[b]Message Types[/b]
HTTP-message = Request | Response ; HTTP/1.1 messages
HTTP messages consist of requests from client to server and responses from server to client
Request and Response messages use the generic message format of RFC 822 for transferring entities
generic-message = start-line
*(message-header CRLF)
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
HTTP/1.1 client MUST NOT preface or follow a request with an extra CRLF
[b]Message Headers[/b]
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>
HTTP header fields, which include general-header, request-header, response-header, and entity-header fields, follow the same generic format as that given in Section 3.1 of RFC 822
Each header field consists of a name followed by a colon (":") and the field value
[b]Message Body[/b]
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response
The message-body differs from the entity-body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding header field
Transfer-Encoding is a property of the message, not of the entity, and thus MAY be added or removed by any application along the request/response chain
A message-body MUST NOT be included in a request if the specification of the request method does not allow sending an entity-body in requests
For response messages, whether or not a message-body is included with a message is dependent on both the request method and the response status code
All responses to the HEAD request method MUST NOT include a message-body, even though the presence of entity-header fields might lead one to believe they do
All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body
All other responses do include a message-body, although it MAY be of zero length.
[b]Message Length[/b]
The transfer-length of a message is the length of the message-body as it appears in the message after any transfer-codings have been applied
If a request contains a message-body and a Content-Length is not given, the server SHOULD respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes to insist on receiving a valid Content-Length
Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding
If the message does include a non-identity transfer-coding, the Content-Length MUST be ignored
When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body
HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected
[b]General Header Fields[/b]
general-header = Cache-Control
| Connection
| Date
| Pragma
| Trailer
| Transfer-Encoding
| Upgrade
| Via
| Warning
New or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize them to be general-header fields
Unrecognized header fields are treated as entity-header fields
[b]Example[/b]
[code]
D:\projects\maui>curl -i http://www.baidu.com
HTTP/1.1 200 OK
Date: Fri, 26 Dec 2008 02:54:34 GMT
Server: BWS/1.0
Content-Length: 4064
Content-Type: text/html
Cache-Control: private
Expires: Fri, 26 Dec 2008 02:54:34 GMT
Set-Cookie: BAIDUID=8738C03034DA31AB6005581059479804:FG=1; expires=Fri, 26-Dec-
8 02:54:34 GMT; path=/; domain=.baidu.com
P3P: CP=" OTI DSP COR IVA OUR IND COM "
<html><head><meta http-equiv=Content-Type content="text/html;charset=gb2312"><ti
tle>百度一下，你就知道 </title>
......
[/code]
可以看到Message Header和Message Body之间有一个CRLF
HTTP-message = Request | Response ; HTTP/1.1 messages
HTTP messages consist of requests from client to server and responses from server to client
Request and Response messages use the generic message format of RFC 822 for transferring entities
generic-message = start-line
*(message-header CRLF)
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
HTTP/1.1 client MUST NOT preface or follow a request with an extra CRLF
[b]Message Headers[/b]
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>
HTTP header fields, which include general-header, request-header, response-header, and entity-header fields, follow the same generic format as that given in Section 3.1 of RFC 822
Each header field consists of a name followed by a colon (":") and the field value
[b]Message Body[/b]
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response
The message-body differs from the entity-body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding header field
Transfer-Encoding is a property of the message, not of the entity, and thus MAY be added or removed by any application along the request/response chain
A message-body MUST NOT be included in a request if the specification of the request method does not allow sending an entity-body in requests
For response messages, whether or not a message-body is included with a message is dependent on both the request method and the response status code
All responses to the HEAD request method MUST NOT include a message-body, even though the presence of entity-header fields might lead one to believe they do
All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body
All other responses do include a message-body, although it MAY be of zero length.
[b]Message Length[/b]
The transfer-length of a message is the length of the message-body as it appears in the message after any transfer-codings have been applied
If a request contains a message-body and a Content-Length is not given, the server SHOULD respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes to insist on receiving a valid Content-Length
Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding
If the message does include a non-identity transfer-coding, the Content-Length MUST be ignored
When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body
HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected
[b]General Header Fields[/b]
general-header = Cache-Control
| Connection
| Date
| Pragma
| Trailer
| Transfer-Encoding
| Upgrade
| Via
| Warning
New or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize them to be general-header fields
Unrecognized header fields are treated as entity-header fields
[b]Example[/b]
[code]
D:\projects\maui>curl -i http://www.baidu.com
HTTP/1.1 200 OK
Date: Fri, 26 Dec 2008 02:54:34 GMT
Server: BWS/1.0
Content-Length: 4064
Content-Type: text/html
Cache-Control: private
Expires: Fri, 26 Dec 2008 02:54:34 GMT
Set-Cookie: BAIDUID=8738C03034DA31AB6005581059479804:FG=1; expires=Fri, 26-Dec-
8 02:54:34 GMT; path=/; domain=.baidu.com
P3P: CP=" OTI DSP COR IVA OUR IND COM "
<html><head><meta http-equiv=Content-Type content="text/html;charset=gb2312"><ti
tle>百度一下，你就知道 </title>
......
[/code]
可以看到Message Header和Message Body之间有一个CRLF
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
