HTTP1.1 Notes 3, HTTP Message 博客分类: Infrastructure 百度Cache
程序员文章站
2024-02-22 16:41:40
...
Message Types
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
Message Headers
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
Message Body
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.
Message Length
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
General Header Fields
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
Example
可以看到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
Message Headers
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
Message Body
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.
Message Length
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
General Header Fields
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
Example
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> ......
可以看到Message Header和Message Body之间有一个CRLF
推荐阅读
-
HTTP1.1 Notes 3, HTTP Message 博客分类: Infrastructure 百度Cache
-
HTTP1.1 Notes 7, Status Code Definitions 博客分类: Infrastructure Access
-
HTTP1.1 Notes 6, Method Definitions 博客分类: Infrastructure Web
-
HTTP1.1 Notes 2, Protocol Parameters 博客分类: Infrastructure 百度SchemeSUNCC++
-
HTTP1.1 Notes 5, Connections 博客分类: Infrastructure Firefox浏览器