HTTP协议

整理自rfc2616

1 HTTP Message
1.1 Message Types
HTTP messages consist of requests from client to server and responses from server to client.
HTTP-message= Request | Response; HTTP/1.1 messages
Request and Response messages use the generic message format of RFC 822 for transferring entities (the payload of the message). Both types of message consist of a start-line, zero 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 possibly a message-body.
generic-message = start-line
                  *(message-header CRLF)
                  CRLF
                  [ message-body ]
start-line        = Request-Line | Status-Line
                 

1.2 Message Headers
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.Field names are case-insensitive.

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 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.
 
1.3 Message Body
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.
message-body = entity-body
             | <entity-body encoded as per Transfer-Encoding>
 
1.4 Message Length
The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied.
 
2 Request
A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use.
Request = Request-Line 
          *(( general-header
            | request-header
            | entity-header ) CRLF)
          CRLF
          [ message-body ]
         

2.1 Request-Line
The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
 
2.1.1 Method
The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.
Method = "OPTIONS"
       | "GET"
       | "HEAD"
       | "POST"
       | "PUT"
       | "DELETE"
       | "TRACE"
       | "CONNECT"
       | extension-method
extension-method = token
 
2.1.2 Request-URI
The Request-URI is a Uniform Resource Identifier and identifies the resource upon which to apply the request.
Request-URI = "*" | absoluteURI | abs_path | authority
 
3 Response
After receiving and interpreting a request message, a server responds with an HTTP response message.
Response = Status-Line
           *(( general-header
             | response-header
             | entity-header ) CRLF)
           CRLF
           [ message-body ]
            

3.1 Status-Line
The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
Status-Line =HTTP-Version SP Status-Code SP Reason-Phrase CRLF
 
3.1.1 Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy there quest. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user.
The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role.There are 5 values for the first digit:
- 1xx: Informational - Request received, continuing process
- 2xx: Success - The action was successfully received, understood, and accepted
- 3xx: Redirection- Further action must be taken in order to complete the request
- 4xx: Client Error - The request contains bad syntax or cannot be fulfilled
- 5xx: Server Error - The server failed to fulfill an apparently valid request