Press conventions, when identifying the application, the components are arranged in its importance.
Product = token ["/" product-version]
Product-Version = Token
E.g:
User-agent: Cern-linemode / 2.15 lowww / 2.17b3
Server: Apache / 0.8.4
The product identity should be short, thus prohibiting the use of this domain to fill in the advertisement or other unrelated information. Although any symbolic characters may appear in the product version, the symbol should only be used to make a version definition, that is, the continuous versions of the same product can only be distinguished by the product version.
4. HTTP Message (HTTP Message)
4.1 Message Types
The HTTP message consists of a request for the client to the server and a response from the server to the client.
Http-message = Simple-request; http / 0.9 Messages
| Simple-Response
Full-Request; HTTP / 1.0 Messages
| Full-Response
Full-Request and full response (full-response) use the message format specified in the Substrate Transport section in RFC822 [7]. The messages of the two may include the title domain (HEADERS, optional), entity body (Entity Body). The entity main body is separated by the blanks (i.e., there is no line before CRLF).
Full-Request = Request-line; Section 5.1
* (General-HEADER; Section 4.3
| Request-header; Section 5.2
| Entity-header; section 7.1
CRLF
[Entity-body]; section 7.2
Full-response = status-line; section 6.1
* (General-HEADER; Section 4.3
| Response-header; Section 6.2
Berners-Lee, et al information [Page 21]
| Entity-header; section 7.1
CRLF
[Entity-body]; section 7.2
Simple request (Simple_Request) and Simple-Response) Does not allow any title information, and limit only the unique request method (GET)
Simple-request = "get" sp Request-URI CRLF
Simple-response = [Entity-body]
It is not advocated to use a simple way to request format because it prevents the server from verifying the media type returned to the entity when the server is connected.
4.2 Message Headers HTTP Title Domain, including the main title (Sequest-Header, 5.2), response title (response-header, 6.2) and physical title (Entity- Header, Section 7.1), all reference to the general format presented by RFC822-3.1 [7]. Each header domain consists of the name of the colon, single spacer (SP), characters, and domain values. The domain name is case sensitive. Although not advocated, the title domain can be extended into multi-line, as long as these lines start in one or more SP or HT.
Http-header = field-name ":" [Field-Value] CRLF
Field-name = token
Field-value = * (Field-Content | LWS)
Field-content = And consisting of each * text or combinations of token, tspecials, and quoted-string> The order in the title domain is not important, but good habits are, first send the master title, then the request title or response title, and finally the entity title. When all the domain values of the title domain are indicated by a comma-separated column (ie, the # (value)), the HTTP title field with the same domain name can be represented in one message. Moreover, it must be able to add the associated domain value to the first value without changing the message syntax, and the multipletles domains can eventually bind to the "domain name" pair in combination with a comma domain. Berners-Lee, et al information [Page 22] 4.3 General Header Fields There are several headings to be used by requests, but do not be used to be transmitted. These headings are only for messages that are transmitted. General-header = date; section 10.6 | Pragma; Section 10.12 The general title domain name can only be reliable only after the change in the change in the protocol version. In fact, the headlines in the new or experiments can be used by the communication parties, and their grammar can be used, and the type of title that cannot be identified will be considered as an entity domain. 5. Request Request messages from the client to the server include, in the header, the request method, the resource identifier and the protocol used for the resource. Considering the backward compatibility of HTTP / 0.9, there are two legal HTTP request formats: REQUEST = Simple-Request | Full-Request Simple-request = "get" sp Request-URI CRLF Full-Request = Request-line; Section 5.1 * (General-HEADER; Section 4.3 Request-header; section 5.2 | Entity-head; section 7.1 CRLF [Entity-body]; section 7.2 If the HTTP / 1.0 server receives a simple request, it must respond to a simple response in an HTTP / 0.9 format. The HTTP / 1.0 client has the ability to receive a complete response, but it cannot produce a simple request. 5.1 Request-line The request queue starts with a method symbol, followed by the request URI and protocol version, ending with CRLF. This element is separated by space SP. A separate CR or LF value is not allowed in addition to the final CRLF. REQUEST-line = Method SP Request-Uri SP HTTP-VERSION CRLF Berners-Lee, et al information [Page 23] Note that the difference between the simple request queue is between the request queue in the full request is whether there is an HTTP version field and whether other methods other than Get can be used. 5.1.1 Method (Method) The method code indicates how many ways to be accessed by request URI will be accessed. The method is case sensitive. Method = "get"; section 8.1 | "HEAD"; section 8.2 | "Pos"; section 8.3 | Extension-Method EXTENSION-METHOD = TOKEN The method list that can access the specified resource is dynamically changed; if accessing the resource with some method, the client can get notified from the return code in response. The server side returns state code 501 (not not implemented) when the method cannot identify or implement the method. These methods are commonly used by the HTTP / 1.0 applications, and see Section 8 for complete definitions. 5.1.2 Request URI (Request-URI) The request URI is the Unified Resource Identifier (Section 3.2) to identify resources to be requested. Request-Uri = Absoluteuri | ABS_PATH The above two requests URI mode can be selected according to the actual request. The absolute URI (ABSOLUTEURI) format is only used when the proxy is generated during the request. The agent's responsibility is to push the request forward and return it back. If the request is a GET or HEAD mode, and the previous response is cached, if the agent ignores the expiration information limit for the title domain, it may use the messages in the cache. Note that the agent may push the request to another agent, or the request can be sent directly to the destination server specified in the absolute URI. To avoid request loops, the agent must be able to identify all of its server names, including alias, local variables, and digital forms of IP addresses. Here is an example of a request queue: Get http://www.w3.org/pub/www/theproject.html http / 1.0 Berners-lee, et al information [Page 24] The most common request URI is the way the original server or gateway is used to identify resources. In this manner, only the URI gives an absolute path can be transmitted (see Section 3.2.1). For example, if the client wants to receive resources directly from the original server, they will generate a TCP connection with the host "www.w3.org" 80 port, and send the following command after the full request: Get / Pub / WWW / theProject .html http / 1.0 Note that the absolute path cannot be empty. If there is no content in the URI, it must be added "/" (Server root). The request URI is transmitted by encoding string, and some characters may be escaped during transmission, such as turning into a "% hexhex" form. For details, please refer to RFC1738 [4]. The original server must decode the request URI before the request is requested. 5.2 Request the title (Request Header Fields) Request the title field allows the client to deliver additional information and client information to the server to the server. This domain is a request for the requesting part, follow the grammatical form of the programming language program to call the parameters. Request-header = authorization; section 10.2 | From; section 10.8 | If-modified-Since; Section 10.9 | Refrer; section 10.13 User-agent; section 10.15 Request the title domain name only after combining the change in the protocol version to make a reliable extension. In fact, the headlines in the new or experiments can be used by the communication parties, and their grammar can be used, and the type of title that cannot be identified will be considered as an entity domain. 6. Respond (response) After receiving, the server side returns an HTTP response message after receiving the request message. Response = Simple-Response | Full-Response Simple-response = [Entity-body] Berners-Lee, et al information [Page 25] Full-response = status-line; section 6.1 * (General-HEADER; Section 4.3 | Response-header; Section 6.2 | Entity-header; section 7.1 CRLF [Entity-body]; section 7.2 When the request is http / 0.9 or when the server is only supports HTTP / 0.9, it can only respond with the Simple-Response method. If the client sends an HTTP / 1.0 full request, the received response is not starting with Status-line, and the client will treat it as a simplicity and analyze it accordingly. Note that simple request only includes the entity main body, which is terminated when the server is closed. 6.1 Status-line The first line of the full response message is the status line. It is composed of the protocol version, the digital form of state code, and the corresponding word language text. Each element is separated, except for the end of CRLF, not allowed separately CR or LF. Status-line = http-version sp status-code sp seed-phrase CRLF The status line always starts with the protocol version and status code, such as: "HTTP /" 1 * DIGIT "." 1 * Digit SP 3Digit SP (Eg, "HTTP / 1.0 200"). This expression is not enough to distinguish the complete request and simple request. Simple response may allow this expression to appear in the beginning of the entity main body, but will cause misunderstandings of the message. Because most HTTP / 0.9 servers can only respond to the "text / html" type, in this case, it is impossible to generate a complete response. 6.1.1 Status Code and Reason Analysis (STATUS CODE AND REASON Phrase) Status-code consists of 3 digits, indicating whether the request is understood or is satisfied. Cause Analysis is the reason why the status code is generated by short text. Status code is used to support automatic operation, and the reason analysis is to prepare for human users. The client does not need to check or display the reason analysis. Berners-Lee, et al information [Page 26] The first digit of the status code defines the category of the response, and the two digits have no specific classification. The first digit has 5 values: o 1xx :: Reserved, in the future. o 2XX: Success - operation is received, understood, accept, accept, understood, accepts. o 3XX: Redirection - To complete the request, further action must be performed. o 4XX: Client error - requests for speech errors or cannot be implemented. o 5XX: The server end error - the server cannot achieve legal requests. The status code of HTTP / 1.0 is explained below. The following reasons are only recommended to use, can be arbitrarily changed without impact on the protocol. The complete code is defined in Section 9. Status-code = "200"; ok | "201"; created | "202"; Accepted | "204"; no content | "301"; MOVED Permanently
