Well worth a look at HTTP article, both basic and in-depth

The first behavior status line in the response message returned by the server contains the status code and reason phrase to inform the client of the result of the request.

• 1 xx information

  • 100 Continue: Indicates that everything is fine so far and the client can Continue sending the request or ignore the response.

• 2 xx success

  • 200 OK
  • 204 No Content: The request has been processed successfully, but the response message returned does not contain the body of the entity. Typically used when you only need to send information from the client to the server without returning data.
  • 206 Partial Content: Indicates that the client sends a Range request. The response packet contains the entity Content specified by Content-range.

• 3 xx redirection

  • 301 Moved Permanently: Permanent redirection
  • 302 Found: Temporary redirection
  • 303 See Other: Provides the same functions as 302, but 303 explicitly requires that the client use the GET method to obtain resources.
  • Note: Most browsers will change POST to GET for 301, 302, and 303 redirects, although HTTP does not allow you to change POST to GET for 301, 302, and 303 redirects.
  • 304 Not Modified: If the request header contains some conditions, for example: If-match, if-modified-since, if-none-match, if-range, if-unmodified-since, If the condition is not met, the server returns the 304 status code.
  • 307 Temporary Redirect: indicates that the browser does not change the POST method to GET method for redirecting requests.

• 4XX Client error

  • 400 Bad Request: Syntax errors exist in the Request packet.
  • 401 Unauthorized: This status code indicates that the request to be sent requires authentication information (BASIC authentication and DIGEST authentication). If the request has been made before, the user authentication failed.
  • 403 Forbidden: The request is rejected.
  • 404 Not Found

• 5XX Server error

  • 500 Internal Server Error: An Error occurred while the Server was performing a request.
  • 503 Service Unavailable: The server is temporarily overloaded or is down for maintenance and cannot process requests now.

The HTTP protocol is stateless, mainly to keep HTTP as simple as possible so that it can handle a large number of transactions. HTTP/1.1 introduced cookies to store state information.

Cookie is a small piece of data that the server sends to the user’s browser and saves locally. It will be carried when the browser sends another request to the same server, which is used to tell the server whether the two requests come from the same browser. Since each subsequent request will need to carry Cookie data, there is an additional performance overhead (especially in a mobile environment).

Cookies were once used to store client data as the only storage method because there was no other suitable storage method, but now as modern browsers begin to support a variety of storage methods, cookies are gradually phased out. New browser apis already allow developers to store data directly locally, such as using the Web Storage API (local and session storage) or IndexedDB.

The response packet sent by the server contains the set-cookie header field. After receiving the response packet, the client saves the Cookie content to the browser.



When the client later sends a request to the same server, it will fetch the Cookie information from the browser and send it to the server through the Cookie request header field.

• The Domain identifier specifies which hosts can accept cookies. If this parameter is not specified, it defaults to the host of the current document (excluding the subdomain name). If Domain is specified, subdomain names are generally included. For example, if you set Domain=mozilla.org, cookies are also included in the subdomain (e.g. Developer.mozilla.org).

• The Path identifier specifies which paths under the host can accept cookies (the URL Path must exist in the request URL). Child paths are also matched with the character %x2F (“/”) as the path separator. For example, if Path=/docs is set, the following addresses will match:

  • /docs
  • /docs/Web/
  • /docs/Web/HTTP

Cookies marked HttpOnly cannot be called by JavaScript scripts. Cross-site scripting attacks (XSS) often use JavaScriptdocument.cookieApis steal users’ Cookie information, so using HttpOnly tags can protect against XSS attacks to some extent.

In addition to storing user information in the browser through cookies, Session can also be used to store information on the server, which is more secure. Sessions can be stored in files, databases, or memory on the server. Sessions can also be stored in an in-memory database such as Redis, which is more efficient. The process of using Session to maintain user login status is as follows:

• When a user logs in, the user submits a form containing the user name and password and sends it to the HTTP request packet.
• The server verifies the user name and password, and if correct, stores the user information in Redis. Its Key in Redis is called Session ID.
• The set-cookie header field of the response packet returned by the server contains the Session ID. After receiving the response packet, the client saves the Cookie value in the browser.
• The Cookie value will be included when the client makes a request to the same server. After receiving the Cookie, the server extracts the Session ID and the user information from Redis to continue the previous business operations.

Note that the Session ID cannot be easily obtained by malicious attackers. In this case, you cannot generate an easily guessed Session ID value. In addition, Session ids need to be regenerated frequently. In scenarios with high security requirements, such as transfer of money, you need to use Session to manage user status and re-authenticate users, such as re-entering passwords or using SMS verification codes.

• Cookies can only store ASCII characters, while sessions can store any type of data. Therefore, Session is preferred when considering data complexity.
• Cookies are stored in a browser and can be viewed maliciously. If you want to store some privacy data in cookies, you can encrypt the Cookie value, and then decrypt it on the server;
• For large web sites, it is very expensive to store all user information in a Session, so it is not recommended to store all user information in a Session.

• Relieve server stress;
• Reduce client latency in obtaining resources: Caches are usually in memory and can be read faster. Also, the cache server may be geographically closer than the source server, such as the browser cache.

HTTP/1.1 controls caching through cache-control header fields.

• Disable caching:no-storeThe directive states that no part of the request or response can be cached.
  
  
• Mandatory confirmation cache:no-cacheThe directive states that the cache server must first verify the validity of the cache resource with the source server, and only when the cache resource is valid can it be used to respond to the client’s request.
  
  
• Private and public caches:privateThe directive specifies that the resource be a private cache that can only be used by individual users and is typically stored in the user’s browser.
  
  
  
  publicThe directive specifies the resource as a common cache that can be used by multiple users and is typically stored in a proxy server.
  
  
• Cache expiration mechanism:max-ageIf an instruction appears in a request message and the cache resource is cached for less than the time specified by the instruction, the cache is accepted.max-ageThe instruction appears in the response message and represents how long the cache resource is held in the cache server.
  
  
  
  ExpiresThe header field can also be used to tell the cache server when the resource will expire.
  
  
  
  在 HTTP / 1.1Is processed preferentiallymax-ageInstruction; inHTTP / 1.0,max-ageInstructions are ignored.

• Server-side driven: The client sets specific HTTP header fields, such as Accept, accept-charset, accept-encoding, and Accept-language, and the server returns specific resources based on these fields. It has the following problems:

  • It is difficult for the server to know all the information about the client’s browser;
  • The information provided by the client is rather verbose (HTTP/2Header compression alleviates this problem) and has privacy risks (HTTP fingerprinting);
  • Given resources need to return different representations, shared caches become less efficient, and server-side implementations become more complex.

• Proxy-driven: The server returns 300 Multiple Choices or 406 Not Acceptable, from which the client selects the most suitable resource.

Content encoding compresses the entity body to reduce the amount of data transferred.

The commonly used content encodings are gzip, COMPRESS, Deflate, and Identity.

The browser sends the accept-Encoding header, which contains the supported compression algorithms and their respective priorities. The server chooses one of these, uses the algorithm to compress the body of the response message, and sends the Content-Encoding header to tell the browser which algorithm it chose. Because the Content negotiation process selects the representation of the resource based on the Encoding type, the Vary header field in the response message must contain at least content-Encoding.

Add the Range header field to the request message to specify the Range of the request.



If the request is successful, the server returns a response containing 206 Partial Content status codes.

• In case the request is successful, the server returns206 Partial ContentStatus code.
• In case the scope of the request is out of bounds, the server returns416 Requested Range Not SatisfiableStatus code.
• In cases where a range request is not supported, the server returns200 OKStatus code.

A message body can contain multiple types of entities and be sent at the same time. Each part is separated by the delimiter defined by the Boundary field. Each part can have a header field. For example, you can upload multiple forms as follows:

Unlike proxy servers, gateway servers convert HTTP to other protocols for communication, thus requesting services from other than HTTP servers.

HTTP has the following security issues:

• Plaintext communications can be intercepted.
• If the identity of the communicating party is not verified, the identity of the communicating party may be disguised;
• The integrity of the packet cannot be proved and the packet may be tampered with.

HTTPS is not a new protocol. It allows HTTP to communicate with SSL (Secure Sockets Layer), and then SSL and TCP, which means HTTPS uses tunnels to communicate. Using SSL, HTTPS has encryption (anti-eavesdropping), authentication (anti-counterfeiting), and integrity protection (anti-tampering).

Symmetric-key Encryption: The same Key is used for Encryption and decryption.

• Advantages: fast operation speed;
• Disadvantages: Cannot securely transfer the key to the communicator.
  
  

As mentioned above, symmetric Key encryption has higher transmission efficiency, but the Secret Key cannot be securely transmitted to the communicator. Asymmetric Key encryption can ensure the security of transmission, so we can use asymmetric Key encryption to transmit the Secret Key to the communicator. HTTPS uses a hybrid encryption mechanism that takes advantage of the scheme mentioned above:

• The asymmetric Key encryption mode is used to transmit the Secret Key required by the symmetric Key encryption mode to ensure security.
• After obtaining the Secret Key, use the symmetric Key encryption mode for communication to ensure efficiency. (The Session Key in the figure below is the Secret Key)
  
  

SSL provides packet summarization to protect packet integrity. HTTP also provides MD5 packet summarization, but it is not secure. For example, if the MD5 value is recalculated after the packet content is tampered, the receiver cannot be aware of the tampering.

The packet summarization function of HTTPS is secure because it combines encryption and authentication. If an encrypted message is tampered with, it is difficult to recalculate the message digest because the plaintext is not readily available.

HTTP/2.0 divides packets into HEADERS frames and DATA frames, both of which are in binary format.

During communication, only one TCP connection exists, which hosts any number of two-way streams.

• A data Stream has a unique identifier and optional priority information for carrying two-way information.
• A Message is a complete set of frames corresponding to a logical request or response.
• Frames are the smallest unit of communication. Frames from different data streams can be sent interlaced and then reassembled according to the data stream identifier of each Frame header.
  
  

HTTP / 1.1“, with a lot of information at the beginning, and repeated each time.HTTP / 2.0Requiring both the client and server to maintain and update a table of previously seen header fields avoids repeated transfers. Not only that,HTTP / 2.0Huffman encoding is also used to compress the header field.

Both GET and POST requests can use additional parameters, but the parameters of GET appear in the URL as a query string, while the parameters of POST are stored in the entity body. Just because the POST parameter is stored in the body of the entity does not mean it is more secure, as it can still be viewed with some packet capture tool (Fiddler).

Because THE URL only supports ASCII codes, if there are Chinese characters in the parameters of GET, they need to be encoded first. For example, Chinese will be converted to%E4%B8%AD%E6%96%87And the space will be converted to% 20. The POST parameter supports the standard character set.

Idempotent HTTP methods, the same request is executed once as many times in a row, and the state of the server is the same. In other words, idempotent methods should not have side effects (except for statistical purposes). All security methods are idempotent. With the right implementation,GET, HEAD, PUT and DELETEAll methods are idempotent, andPOSTThe method is not.GET/pageX HTTP / 1.1Is idempotent, and the client receives the same result for multiple consecutive calls:



POST/add_row HTTP / 1.1Not idempotent, if called more than once, multiple lines will be added:



DELETE/independence idX/DELETE HTTP / 1.1Is idempotent, even if different requests receive different status codes:

To illustrate another difference between POST and GET, you need to understand XMLHttpRequest: XMLHttpRequest is an API that provides a client with the ability to transfer data between the client and the server. It provides an easy way to get data through a URL without having to refresh the entire page. This allows the web page to update only a portion of the page without disturbing the user. XMLHttpRequest is widely used in AJAX.

• When using the POST method of XMLHttpRequest, the browser sends the Header first and then the Data. But not all browsers do this. Firefox, for example, does not.
• The GET methods Header and Data are sent together.