RFC2616 HTTP/1.1

*************************************************************************************************
目录
1 Introduction
2 Notational Conventions and Generic Grammar
3 Protocol Parameters
4 HTTP Message
5 Request
6 Response
7 Entity
8 Connections
9 Method Definitions
10 Status Code Definitions
*************************************************************************************************
1 Introduction


1.4 Overall Operation

There are three common forms of intermediary: proxy, gateway, and tunnel.

A proxy is a forwarding agent, receiving requests for a URI in its absolute form, rewriting all or part of the message, and forwarding the reformatted request toward the server identified by the URI.

A gateway is a receiving agent, acting as a layer above some other server(s) and, if necessary, translating the requests to the underlying server’s protocol.

A tunnel acts as a relay point between two connections without changing the messages; tunnels are used when the communication needs to pass through an
intermediary (such as a firewall) even when the intermediary cannot understand the contents of the messages.

This distinction is important because some HTTP communication options may apply only to the connection with the nearest, nontunnel
neighbor, only to the end-points of the chain, or to all connections along the chain.


In HTTP/1.0, most implementations used a new connection for each request/response exchange.
In HTTP/1.1, a connection may be used for one or more request/response exchanges, although connections may be closed for a variety of reasons (see section 8.1).

*************************************************************************************************
2 Notational Conventions and Generic Grammar


2.1 Augmented BNF


name = definition
"literal"
rule1 | rule2
(rule1 rule2)
*rule
[rule]   =   *1(foo bar) 可选项
N rule   =   <n>*<n>(element)
#rule  逗号分隔的列表
; comment
implied *LWS  linear white space



2.2 Basic Rules

OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>

CRLF = CR LF
LWS = [CRLF] 1*( SP | HT )
TEXT = <any OCTET except CTLs,but including LWS>
HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
token = 1*<any CHAR except CTLs or separators>

separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT

comment = "(" *( ctext | quoted-pair | comment ) ")"
ctext = <any TEXT excluding "(" and ")">

quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <any TEXT except <">>

quoted-pair = "\" CHAR

*************************************************************************************************
3 Protocol Parameters

3.1 HTTP Version

The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message.
       HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Note that the major and minor numbers MUST be treated as separate integers and that each MAY be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than
HTTP/2.13, which in turn is lower than HTTP/12.3.

The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.


3.2 Uniform Resource Identifiers

The HTTP protocol does not place any a priori limit on the length of a URI.
Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]


3.3 Date/Time Formats

       Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
       Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
       Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format




HTTP-date    = rfc1123-date | rfc850-date | asctime-date
       rfc1123-date = wkday "," SP date1 SP time SP "GMT"
       rfc850-date  = weekday "," SP date2 SP time SP "GMT"
       asctime-date = wkday SP date3 SP time SP 4DIGIT
       date1        = 2DIGIT SP month SP 4DIGIT
                      ; day month year (e.g., 02 Jun 1982)
       date2        = 2DIGIT "-" month "-" 2DIGIT
                      ; day-month-year (e.g., 02-Jun-82)
       date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
                      ; month day (e.g., Jun  2)
       time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
                      ; 00:00:00 - 23:59:59
       wkday        = "Mon" | "Tue" | "Wed"
                    | "Thu" | "Fri" | "Sat" | "Sun"
       weekday      = "Monday" | "Tuesday" | "Wednesday"
                    | "Thursday" | "Friday" | "Saturday" | "Sunday"
       month        = "Jan" | "Feb" | "Mar" | "Apr"
                    | "May" | "Jun" | "Jul" | "Aug"
                    | "Sep" | "Oct" | "Nov" | "Dec"


3.4 Character Sets

HTTP uses the same definition of the term “character set” as that described for MIME.


3.5 Content Codings

gzip
compress
deflate
identity

3.6 Transfer Codings
Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to an entity-body in order to ensure “safe transport” through the network.
This differs from a content coding in that the transfer-coding is a property of the message, not of the original entity.

3.7 Media Types
3.8 Product Tokens
3.9 Quality Values
3.10 Language Tags
3.11 Entity Tags
3.12 Range Units

*************************************************************************************************
4 HTTP Message

4.1 Message Types
HTTP-message   = Request | Response     ; HTTP/1.1 messages

generic-message = start-line
                  *(message-header CRLF)
                  CRLF
                  [ message-body ]
start-line      = Request-Line | Status-Line

4.2 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>


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.

4.3 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.

4.4 Message Length

Content-Length 和 Transfer-Encoding的关系。

4.5 General Header Fields

general-header = Cache-Control          
                      | Connection            
                      | Date                 
                      | Pragma                 
                      | Trailer               
                      | Transfer-Encoding     
                      | Upgrade                
                      | Via                   
                      | Warning                


*************************************************************************************************                         
5 Request             
Request       = Request-Line    
                        *(  (general-header| request-header| entity-header ) CRLF)
                        CRLF
                        [ message-body ]   

5.1 Request-Line

Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

       Method         = "OPTIONS"            
                      | "GET"                
                      | "HEAD"               
                      | "POST"               
                      | "PUT"                
                      | "DELETE"             
                      | "TRACE"              
                      | "CONNECT"            
                      | extension-method
       extension-method = token             

Request-URI    = "*" | absoluteURI | abs_path | authority

5.2 The Resource Identified by a Request
Request-URI和HOST的组合。

5.3 Request Header Fields

      
*************************************************************************************************                         
6 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 ]        
6.1 Status-Line
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

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


6.2 Response Header Fields

*************************************************************************************************                         
7 Entity
Request and Response messages MAY transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header fields and an entity-body, although some responses will only
include the entity-headers.

7.1 Entity Header Fields
7.2 Entity Body
entity-body    = *OCTET
*************************************************************************************************   
8 Connections        
8.1 Persistent Connections

Persistent Connections的优点.
1 By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts.
2 HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time.
3 Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to determine the congestion state of the network.
4 Latency on subsequent requests is reduced since there is no time spent in TCP’s connection opening handshake.
5 HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection. Clients using future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with old semantics after an error is reported.


A client that supports persistent connections MAY “pipeline” its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.


8.2 Message Transmission Requirements          
*************************************************************************************************                         
9 Method Definitions
9.1 Safe and Idempotent Methods
Safe Methods 安全方法
Idempotent Methods 幂等性
9.2 OPTIONS
9.3 GET
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.
conditional GET 有条件的GET。
partial GET 部分GET。
9.4 HEAD
The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.
GET的降级版。
This method is often used for testing hypertext links for validity, accessibility, and recent modification.
9.5 POST
The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.
Annotation of existing resources;
Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
Providing a block of data, such as the result of submitting a form, to a data-handling process;
Extending a database through an append operation.
9.6 PUT
The PUT method requests that the enclosed entity be stored under the supplied Request-URI.

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That
resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent
knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the
user agent MAY then make its own decision regarding whether or not to redirect the request.
9.7 DELETE
The DELETE method requests that the origin server delete the resource identified by the Request-URI.
9.8 TRACE
The TRACE method is used to invoke a remote, application-layer loop-back of the request message.
TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information.
9.9 CONNECT
*************************************************************************************************                         
10 Status Code Definitions

10.2.1  200 OK
The request has succeeded. The information returned with the response is dependent on the method used in the request.

10.3.3  302 Found
The requested resource resides temporarily under a different URI.

10.4.1  400 Bad Request
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

10.4.4  403 Forbidden
The server understood the request, but is refusing to fulfill it.

10.4.5  404 Not Found
The server has not found anything matching the Request-URI.

10.5.1  500 Internal Server Error
The server encountered an unexpected condition which prevented it from fulfilling the request.

10.5.6  505 HTTP Version Not Supported
The server does not support, or refuses to support, the HTTP protocol version that was used in the request message.
*************************************************************************************************                         
*************************************************************************************************