HTTP Knowledge Collation

HTTP protocolThe main features of the HTTP protocol can be summarized as follows:
1. Support client/server mode.
2. Simple and quick: When a client requests a service from a server, it simply transmits the request method and path. The request method commonly has, POST. Each method prescribes a different type of customer contact with the server. Because the HTTP protocol is simple, the HTTP server's program is small, so the communication speed is very fast.
3. Flexible: HTTP allows the transfer of any type of data object. The type being transferred is marked by Content-type.
4. No connection: The implication 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 a reply from the customer, 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 capability for transaction processing. A lack of status means that if the preceding information is required for subsequent processing, it must be retransmission, which may result in an increase in the amount of data transmitted per connection. On the other hand, it responds faster when the server does not need prior information.

HTTP request

HTTP requests consist 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 methods; Request-uri is a Uniform resource identifier; Http-version represents the HTTP protocol version of the request; The CRLF represents a carriage return and a newline (except that a separate CR or LF character is not allowed in addition to the CRLF at the end).
The request method (all uppercase) has a variety of methods, and each method is interpreted as follows: Get request gets request-uri the resource identified by the Request-uri appends a new data head to the resource identified by the Request to obtain the response message header put request server for the resource identified by Request-uri to store a resource and use Request-uri as its identity delete request Server Delete Request-uri identified resource TRACE Request information received by the requesting server, primarily for testing or diagnostics CONNECT to reserve the ability to query the server for future use of the options request, or to query for 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 composed 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 a textual description of the status code.
The status code is composed of three digits, the first number defines the category of the response, and there are five possible values: 1xx: Indicates the message--indicates that the request has been received, continues processing 2xx: Success--Indicates that the request has been successfully received, understood, accepted 3xx: Redirect--requires further action to complete the request 4XX: Client Error--Request has syntax error or request cannot implement 5XX: server-side Error-Server failed to implement legitimate request HTTP message

HTTP messages consist of requests from the client to the server and responses from the server to the client. 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 row), and the message body (optional).
The HTTP message header includes a normal header, a request header, a response header, and an entity header. Each header field is made up of the name + ":" + space + value, and the name of the message header field is case independent.
1. General Header

In the normal header, a few header fields are used for all requests and response messages, but not for the transmitted entities, only for the transmitted messages.
Cache-control is used to specify a caching instruction, the cache instruction is one-way (the cached instruction appearing in the response may not appear in the request), and is independent (a message's caching instruction does not affect the caching mechanism of another message processing), and HTTP1.0 uses a similar header domain as pragma.
The cached instruction at request includes: 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;
The caching instructions for the 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 deliver additional information about the request to the server and the client itself. The
commonly used request headers
1 Accept
Accept request header domain 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 format; accept:text/html, which indicates that the client wants to accept HTML text. The
2) accept-charset
Accept-charset request header field is used to specify the character set accepted by the client. eg:accept-charset:iso-8859-1,gb2312. If you do not set this field in the request message, the default is that any character set is acceptable. The
3) accept-encoding
accept-encoding request header field is similar to Accept, but it is used to specify an 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. The
4) accept-language
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 domain is not set in the request message, the server assumes that the client is acceptable to all languages. The
5) Authorization
Authorization request header domain is primarily used to prove that the client has permission to view a resource. When a browser accesses a page, if the response code received from the server is 401 (not authorized), you can send a request containing the authorization request header domain to require the server to authenticate it.
6) Host
When the request is sent, 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. The
7) user-agent
User-agent request header domain allows clients 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 2007 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 row, as well as information about the server and the next access to resources identified by Request-uri.
Frequently used response headers
1) Location
The Location response header field is used to redirect the recipient to a new location. The location response header domain is often used when changing a domain name.
2) Server
The server Response header field contains the software information that the servers use to process the request. Corresponds to the user-agent request header domain.
4, Entity header

A

Request and response message can transfer an entity. An entity consists of an Entity header field and an entity body, but does not mean that the entity header field and the entity body are sent together, and that only the Entity header field can be sent. The entity header defines meta information about the entity body and the resources identified by the request.
commonly used entity headers:
1) content-encoding
content-encoding entity header field is used as a modifier for the media type, and its value indicates the encoding that has been applied to the additional content of the entity body. Therefore, to obtain the media types referenced in the Content-type header domain, the corresponding decoding mechanism must be used. Content-encoding the compression method that is used to record documents, Eg:content-encoding:gzip
2) content-language
The Content-language Entity header field describes the natural language used by the resource. Without setting the domain, the entity content is considered to be available to all language readers. The
3) content-length
Content-length entity header field is used to indicate the length of the entity body and decimal digits stored in bytes. The
4) content-type
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 date and time the resource was last modified.
6) Expires
Expires The Entity header field gives the date and time the response expired. HTTP1.0 and HTTP1.1 difference 1, long connection

In the 1.0 version, if the client request header is not set to connection:keep-alive, the connection is disconnected every time the request completes, and the client has to re-establish an HTTP connection. Suppose a page contains 10 pictures, so in order to request a picture, The client must send 10 requests, no doubt this is a huge waste of bandwidth and resources, the advantages of TCP is 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 closing the connection.
2, Host header field

In HTTP1.0, each server is considered bound to a unique IP address, so the URL in the request message does not pass the host name (hostname). But with the development of virtual host technology, multiple virtual hosts can exist on a single physical server (multi-homed Web Servers), and they share an IP address. Both the request and response messages for HTTP1.1 should support the host header domain, and if there is no Host header field in the request message, an error (Bad request) is reported. 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 first-only domain request, and if the server rejects the request because of the permission, the response code 401 (unauthorized) is sent back, and the client can continue to send the full request with the entity if the server receives the request with ECHO response code 100. The use of Continue status code, allows the client to send request message body before using the request header to test the server, see server to receive request body, and then decide whether to send request Body

HTTP1.0 does not define any specific 1XX status code, HTTP1.1 has 2
Continue
switching Protocols 203
Information
205 Reset Content
206 Partial Content
302 Found (in HTTP1.0 302 moved)
temporarily Ther
305 use Proxy
307 temporary Redirect
405 cannot 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 answer message is sent throughout, and the Content-length 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 pages are dynamically generated , so the result is that if the content-length is shorter than the actual length, it will cause the content to be truncated, and if it is longer than the entity content, it will cause pending, and the browser is content-length.
So in HTTP1.1, transfer-encoding is introduced, if an HTTP message (Request message or answer message) transfer-encoding The value of the message header is chunked, then the message body consists of an undetermined number of blocks, And ends with the last block of size 0. If both Content-length and transfer-encoding are set, the transfer-encoding priority is higher and content-length is ignored.
5, caching

In http/1.0, the Expire header field is used to determine the fresh or stale of the resource, and the conditional request (conditional request) is used to determine whether the resource is still valid. For example, The cache server verifies that the resource's last-modefied header domain is updated through the If-modified-since header domain and the source server may return 304 (not Modified), indicating that the object is still valid; Replaces the requested cache object.
In addition, the Pragma:no-cache header domain is defined in http/1.0, and the client uses the header field to state that the request resource cannot be fetched from the cache and must be retrieved from the source. http/1.1 has added some new cache features on the basis of 1.0, when the age of the cached object becomes stale object, 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 lead to clock synchronization problems on different machines. and http/1.1 introduced a 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 adds Cache-control header fields (both request and response messages are available), and it supports an extensible subset of instructions: for example, max-age instruction supports relative timestamp; Private and No-store directives prohibit objects from being cached; No-transform prevents the proxy from making any changes to the response.
Cache uses the keyword index to use the resource's URL as a keyword in the http/1.0 object that is cached on the disk. But there may be different resources based on the same URL, and to differentiate them requires more information from the client, such as Accept-language and Accept-charset header fields. In order to support this content negotiation mechanism (contents negotiation mechanism), http/1.1 introduced the vary header domain in the response message. This header field lists which header fields are required for content negotiation in the request message.the difference between HTTP1.1 and HTTP2.0