HTTP Knowledge Collation

HTTP protocolThe main features of the HTTP protocol can be summarized as follows:
1. Support client/server mode.
2. Simple and fast: When a customer requests a service from the server, it simply transmits the request method and path. The request method commonly has, POST. Each method specifies a different type of contact between the customer and the server. Because the HTTP protocol is simple, the HTTP server's program size is small, so the communication speed is fast.
3. Flexible: HTTP allows the transfer of any type of data object. The type being transmitted is marked by Content-type.
4. No connection: The meaning of no connection is to limit the processing of only one request per connection. When the server finishes processing the customer's request and receives the customer's answer, the connection is disconnected. In this way, the transmission time can be saved.

5. Stateless: The HTTP protocol is a stateless protocol. Stateless means that the protocol has no memory capacity for transactional processing. A lack of state means that if the previous information is required for subsequent processing, it must be re-routed, which may cause the amount of data to be transferred per connection to increase. On the other hand, it responds faster when the server does not need the previous information.

HTTP request

The HTTP request consists of three parts: the request line, the message header, and the request body.
Request Line format: Method Request-uri http-version CRLF
Where method represents the request approach; Request-uri is a Uniform resource identifier; Http-version represents the HTTP protocol version of the request; CRLF indicates carriage return and newline (except for the CRLF at the end, a separate CR or LF character is not allowed).
The request method, which is all capitalized, is interpreted as follows: Get request gets the resource identified by Request-uri post in the resource identified by Request-uri append new data HEAD Request to obtain a response message for a resource identified by Request-uri the PUT request server stores a resource and uses Request-uri as its identity delete request server to delete the resource identified by the Request-uri TRACE Requests the server to echo received request information, primarily for testing or diagnosing CONNECT reserved future use of the Options request query server performance, or query resource-related options and requirements HTTP response

After receiving and interpreting the request message, the server returns an HTTP response message.
The HTTP response is also made up of three parts: the status line, the message header, and the response body.
Status line format: Http-version status-code reason-phrase CRLF
Where http-version represents the version of the server HTTP protocol, Status-code represents the response status code sent back by the server, and Reason-phrase represents a textual description of the status code.
The status code consists of three digits, the first number defines the category of the response, and there are five possible values: 1xx: Indicates that the request has been received and continues processing 2xx: Success-Indicates that the request has been successfully received, understood, accepted 3xx: Redirect--must be further manipulated to complete the request 4XX: Client Error--Request syntax error or request not implemented 5XX: server-side Error-Server failed to implement legitimate request HTTP message

HTTP messages consist of client-to-server requests and server-to-client responses. Both the request message and the response message are from the start line (for the request message, the start line is the request line, for the response message, the start line is the status line), the message header (optional), the empty line (only the CRLF line), and the message body (optional) is composed.
The HTTP message header includes the normal header, the request header, the response header, and the entity header. Each header field consists of a name + ":" + a Space + value, and the name of the message header field is case-insensitive.
1. Normal header

In the normal header, a small number of header fields are used for all request and response messages, but not for the transferred entity, only for the transmitted messages.
The Cache-control is used to specify the cache instruction, the cache instruction is unidirectional (the cache instruction appearing in the response may not appear in the request), and is independent (the cache instruction of one message does not affect the caching mechanism of another message processing), and HTTP1.0 uses a similar header domain of pragma.
Cache directives at request include: No-cache (used to indicate that the request or response message cannot be cached), No-store, Max-age, Max-stale, Min-fresh, only-if-cached;
Cache directives for response include: public, Private, No-cache, No-store, No-transform, Must-revalidate, Proxy-revalidate, Max-age, S-maxage.
2. Request Header

The

Request header allows the client to pass additional information about the request to the server side, as well as the client itself.
Common Request Header
1) The Accept
Accept Request header field is used to specify which types of information the client accepts. Eg:accept:image/gif, indicating that the client wants to accept a resource in GIF image format; accept:text/html, indicating that the client wants to accept HTML text.
2) Accept-charset
The Accept-charset request header field is used to specify the character set accepted by the client. eg:accept-charset:iso-8859-1,gb2312. If the field is not set in the request message, the default is to accept any character set.
3) accept-encoding
The accept-encoding request header field is similar to accept, but it is used to specify acceptable content encoding. Eg:accept-encoding:gzip.deflate. If the domain server is not set in the request message, the client is assumed to be acceptable for various content encodings.
4) Accept-language
The Accept-language request header field is similar to Accept, but it is used to specify a natural language. EG:ACCEPT-LANGUAGE:ZH-CN. If the header field is not set in the request message, the server assumes that the client is acceptable for each language.
5) Authorization
The Authorization request header domain is primarily used to prove that a client has permission to view a resource. When a browser accesses a page, if a response code of 401 (unauthorized) is received from the server, a request containing the authorization request header domain can be sent, requiring the server to validate it.
6) Host
When sending a request, the header field is required. The host request header domain is primarily used to specify the Internet host and port number of the requested resource, which is typically extracted from the HTTP URL.
7) User-agent
The User-agent request header field allows the client to tell the server about its operating system, browser, and other properties. This header field is not required.
Request Header Example:

Get/form.html http/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash, application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF)
ACCEPT-LANGUAGE:ZH-CN ( CRLF)
accept-encoding:gzip,deflate (CRLF)
if-modified-since:wed,05 Jan 11:21:25 GMT (CRLF)
if-none-match:w/"80b1a4c018f3c41:8317" (CRLF)
user-agent:mozilla/4.0 (compatible; MSIE6.0; Windows NT 5.0) (CRLF)
Host:www.guet.edu.cn (CRLF)
connection:keep-alive (CRLF)
(CRLF)

3. Response header

The response header allows the server to pass additional response information that cannot be placed in the status line, as well as information about the server and the next access to the resources identified by Request-uri.
Common response Headers
1) Location
The Location response header field is used to redirect the recipient to a new position. Location response header fields are commonly used when changing domain names.
2) Server
The server Response header field contains the software information that the server uses to process the request. Corresponds to the User-agent request header field.
4. Entity Header

Both the

Request and response messages can pass an entity. An entity consists of an Entity header field and an entity body, but it does not mean that the entity header fields and entity bodies are sent together, and only the entity header fields can be sent. The entity header defines the meta information about the entity body and the resource identified by the request.
Common Entity Header:
1) The content-encoding
content-encoding entity header field is used as a modifier for the media type, and its value indicates the encoding of additional content that has been applied to the entity body, Therefore, to obtain the media type referenced in the Content-type header domain, the corresponding decoding mechanism must be used. Content-encoding This compression method for documenting documents, Eg:content-encoding:gzip
2) content-language
The Content-language Entity header field describes the natural language used by the resource. The domain is not set and the entity content is considered to be available to all language readers.
3) Content-length
The Content-length entity header field is used to indicate the length of the entity body, expressed as a decimal number stored in bytes.
4) Content-type
The Content-type entity header field is used to indicate the media type that is sent to the recipient's entity body. Eg:
content-type:text/html;charset=iso-8859-1
content-type:text/html;charset=gb2312
5) Last-Modified The
last-modified entity header field is used to indicate the last modification date and time of the resource.
6) Expires
The Expires Entity header field gives the date and time when the response expires. HTTP1.0 and HTTP1.1 differences 1, long connection

In version 1.0, if the client request header is not set connection:keep-alive, the connection is immediately disconnected every time the request is completed, and the client then re-establishes an HTTP connection. Suppose a webpage contains 10 images, in order to request a picture, The client must send 10 requests, no doubt this is a huge waste of bandwidth and resources, and the advantages of TCP are not reflected. In HTTP1.1, Keep-alive has been deprecated (but most servers and browsers retain this option). In the 1.1 version, Persistent connections are enabled by default, unless you explicitly include connection:close in the response header and the client receives a response before it closes the connection.
2. Host Header domain

In HTTP1.0, each server is considered to be bound to a unique IP address, so the URL in the request message does not have a host name (hostname). However, with the development of virtual host technology, multiple virtual hosts can exist on a physical server (multi-homed Web Servers), and they share an IP address. Both the request message and the response message for HTTP1.1 should support the host header domain, and an error is reported in the request message if there is no Host header field ("Bad Request"). In addition, The server should accept resource requests marked with an absolute path.
3. Request Method

HTTP1.1 adds options, PUT, DELETE, TRACE, connect these request methods.
HTTP1.1 Added new status code:
The client sends a lead-only domain request, and if the server rejects the request because of the permission, the Echo Response code 401 (unauthorized) is sent back, and if the server receives this request, the client can continue to send the full request with the entity with the Echo Response code 100. The use of the Continue status code allows the client to test the server with the request header before sending the request message body, to see if the server wants to receive the request body, and then decide whether to send the request Body

HTTP1.0 does not define any specific 1XX status code, HTTP1.1 has 2
Continue
101 switching Protocols 203 non-authoritative
Information
205 Reset content
206 Partial content
302 Found (There is a HTTP1.0 302 Moved in temporarily)
303 see O Ther
305 use Proxy
307 temporary Redirect
405 Method not allowed
406 not acceptable
407 Proxy authe Ntication Required
408 Request Timeout
409 Conflict 410 Gone 411
Length Required
412 Precondition Failed
413 Request Entity Too Large 414 request-uri
Too Long
415 unsupported Media Type
416 requested Range not satisfiable
417 expectation Failed
504 Gateway Timeout
505 HTTP Version not support Ed

4. Content Length

The data sent in the HTTP reply message is sent throughout, and the Content-length message header field represents the length of the data. The length of the data is important because the client needs to know where the answer message ends and the start of the subsequent reply message. But in some dynamic web pages, because the Web page is dynamically generated , so it is impossible to calculate accurate content-length, so the result is: If the content-length is shorter than the actual length, it will cause the content to be truncated, if it is longer than the entity content, will cause pending, the browser has been spinning.
So the transfer-encoding is introduced in HTTP1.1, if the value of the transfer-encoding message header of an HTTP message (Request message or reply message) is chunked, then the body of the message consists of an indeterminate number of blocks, And ends with the last block of size 0. If both Content-length and transfer-encoding are set, the transfer-encoding is higher, and content-length is ignored.
5. Cache

In http/1.0, use the Expire header field to determine the fresh or stale of a resource and use a conditional request (conditional request) to determine whether the resource is still valid. For example, The cache server verifies that the last-modefied header domain of the resource is updated through the If-modified-since header domain, that the source server may return 304 (not Modified), that the object is still valid, or that it may return a (OK) Replace the requested cache object.
In addition, the Pragma:no-cache header domain is also defined in http/1.0, which the client uses to indicate that the request resource cannot be fetched from the cache and must be fetched back to the source. http/1.1 adds some new features to the cache based on 1.0, when the cached object becomes stale object when age exceeds expire, the cache does not need to discard the stale object directly, but is reactivated with the source server (revalidation).
In http/1.0, the if-modified-since header domain uses an absolute timestamp, which is accurate to the second, but using absolute time can cause clock synchronization problems on different machines. and http/1.1 introduced an ETag header field for the reactivation mechanism, its value entity Tag can be used to uniquely describe a resource. The If-none-match header field can be used in the request message to match whether the entitytag of the resource has changed.
To make the caching mechanism more flexible, http/1.1 increases the Cache-control header domain (both request and response messages are available), which supports an extensible subset of instructions: For example, max-age commands support relative timestamps; The private and No-store directives prohibit the object from being cached; No-transform block proxy from any behavior that alters the response.
The cache uses the keyword index for objects cached on disk, using the URL of the resource as a keyword in http/1.0. But there may be different resources based on the same URL, and to differentiate them requires more information from the client. such as the Accept-language and Accept-charset header domains. To support this content-negotiation mechanism (contents negotiation mechanism), http/1.1 introduced the vary header domain in the response message. The header field lists which header fields are required in the request message for content negotiation.HTTP1.1 and HTTP2.0 differences