HTTP

on Jun 1, 2014, tagged translations, introductions, http, protocols, link-lists (share this post, e.g., on Mastodon or on Bluesky)

The content of this article comes from books and online resources.

I. Basic Concepts

URI

URI includes both URL and URN.

Request and Response Messages

1. Request Message

2. Response Message

II. HTTP Methods

The client sends a request message where the first line is the request line, containing the method field.

GET

Retrieve resource.

In current network requests, the vast majority use the GET method.

HEAD

Retrieve message headers.

Similar to the GET method, but does not return the message entity body part.

Mainly used to confirm URL validity and resource update date/time, etc.

POST

Transmit entity body.

POST is mainly used to transmit data, while GET is mainly used to retrieve resources.

For more comparisons between POST and GET, please refer to Chapter IX.

PUT

Upload file.

Since it does not have its own authentication mechanism, anyone can upload files, which creates security issues; therefore, this method is generally not used.

PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 16

<p>New File</p>

PATCH

Perform partial modifications to resources.

PUT can also be used to modify resources, but can only completely replace the original resource; PATCH allows partial modifications.

PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100

[description of changes]

DELETE

Delete file.

Opposite function to PUT, and similarly lacks an authentication mechanism.

DELETE /file.html HTTP/1.1

OPTIONS

Query supported methods.

Query what methods the specified URL supports.

Will return content like Allow: GET, POST, HEAD, OPTIONS.

CONNECT

Require establishing a tunnel when communicating with proxy servers.

Uses SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols to encrypt communication content and transmit it over network tunnels.

CONNECT www.example.com:443 HTTP/1.1

TRACE

Trace path.

The server returns the communication path back to the client.

When sending a request, enter a value in the Max-Forwards header field; it decreases by 1 each time it passes through a server, and transmission stops when the value reaches 0.

TRACE is typically not used, and it is susceptible to XST attacks (Cross-Site Tracing).

III. HTTP Status Codes

The response message returned by the server has a status line as its first line, containing the status code and reason phrase, which informs the client of the request result.

1XX Informational

• 100 Continue: Indicates everything is normal so far; the client can continue sending the request or ignore this response.

2XX Success

• 200 OK
• 204 No Content: Request successfully processed, but the response message does not contain an entity body. Generally used when only information needs to be sent from client to server, with no data return needed.
• 206 Partial Content: Indicates the client performed a range request; the response message contains entity content within the range specified by Content-Range.

3XX Redirection

• 301 Moved Permanently: Permanent redirection.
• 302 Found: Temporary redirection.
• 303 See Other: Has the same function as 302, but 303 explicitly requires the client to use the GET method to retrieve the resource.
• Note: Although the HTTP protocol stipulates that POST methods should not be changed to GET methods during 301 or 302 redirections, most browsers will change POST to GET under 301, 302, and 303 redirection statuses.
• 304 Not Modified: If the request message header contains conditions such as If-Match, If-Modified-Since, If-None-Match, If-Range, or If-Unmodified-Since, and conditions are not met, the server returns status code 304.
• 307 Temporary Redirect: Temporary redirection, similar in meaning to 302, but 307 requires browsers not to change the redirected request’s POST method to GET method.

4XX Client Error

• 400 Bad Request: Syntax errors exist in the request message.
• 401 Unauthorized: This status code indicates the request requires authentication information (BASIC authentication, DIGEST authentication). If a request was previously made, it indicates user authentication failed.
• 403 Forbidden: Request rejected.
• 404 Not Found

5XX Server Error

• 500 Internal Server Error: An error occurred while the server was executing the request.
• 503 Service Unavailable: Server is temporarily overloaded or undergoing maintenance shutdown; currently unable to process requests.

IV. HTTP Headers

There are four types of header fields: General Header Fields, Request Header Fields, Response Header Fields, and Entity Header Fields.

Various header fields and their meanings are as follows (full memorization not required; for reference only):

General Header Fields

Request Header Fields

Response Header Fields

Entity Header Fields

V. Practical Applications

Connection Management

1. Short Connections and Long Connections

When a browser accesses an HTML page containing multiple images, in addition to requesting the HTML page resource, it also requests image resources. If a new TCP connection is created for each HTTP communication, the overhead is substantial.

Long connections only need one TCP connection established to conduct multiple HTTP communications.

• Starting from HTTP/1.1, long connections are the default; to disconnect, either the client or server must propose disconnection using Connection: close.
• Before HTTP/1.1, short connections were the default; if long connections are needed, use Connection: Keep-Alive.

2. Pipelining

By default, HTTP requests are sent sequentially; the next request is only sent after the current request receives a response. Due to network latency and bandwidth limitations, a long wait may be required before the next request is sent to the server.

Pipelining sends requests continuously on the same long connection without waiting for responses to return, thereby reducing latency.

Cookie

The HTTP protocol is stateless, primarily to keep the protocol as simple as possible, enabling it to handle massive transactions. HTTP/1.1 introduced cookies to preserve state information.

A cookie is a small piece of data sent by the server to the user’s browser and saved locally; it will be carried when the browser subsequently initiates a request to the same server, informing the server whether two requests originate from the same browser. Since each subsequent request needs to carry cookie data, this creates additional performance overhead (especially in mobile environments).

Cookies were once used for client-side data storage because there were no suitable storage alternatives at the time, serving as the sole storage mechanism. However, with modern browsers now supporting various storage methods, cookies are gradually being phased out. New browser APIs now allow developers to store data directly locally, such as using the Web Storage API (local storage and session storage) or IndexedDB.

1. Usage

• Session state management (such as user login status, shopping cart, game scores, or other information needing recording)
• Personalized settings (such as user-customized settings, themes, etc.)
• Browser behavior tracking (such as tracking and analyzing user behavior, etc.)

2. Creation Process

The response message sent by the server contains the Set-Cookie header field; after receiving the response message, the client saves the cookie content in the browser.

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]

When the client subsequently sends a request to the same server, it retrieves cookie information from the browser and sends it to the server via the Cookie request header field.

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

3. Classification

• Session Cookies: Automatically deleted after the browser closes; effective only during the session period.
• Persistent Cookies: After specifying an expiration time (Expires) or validity period (max-age), they become persistent cookies.

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

4. Scope

Domain specifies which hosts can accept cookies. If not specified, the default is the current document’s host (excluding subdomains). If Domain is specified, it generally includes subdomains. For example, if setting Domain=mozilla.org, the cookie also applies to subdomains (such as developer.mozilla.org).

Path specifies which paths under the host can accept cookies (the URL path must exist in the request URL). The character %x2F (“/”) serves as the path separator; subpaths will also be matched. For example, setting Path=/docs means the following addresses will match:

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

5. JavaScript

Browsers can create new cookies through the document.cookie attribute, and can also access non-HttpOnly-marked cookies through this attribute.

document.cookie = "yummy_cookie=choco";
document.cookie = "tasty_cookie=strawberry";
console.log(document.cookie);

6. HttpOnly

Cookies marked as HttpOnly cannot be called by JavaScript scripts. Cross-site scripting attacks (XSS) often use JavaScript’s document.cookie API to steal users’ cookie information; therefore, using the HttpOnly mark can avoid XSS attacks to some extent.

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

7. Secure

Cookies marked as Secure can only be sent to the server through requests encrypted by the HTTPS protocol. However, even with the Secure mark set, sensitive information should not be transmitted through cookies, because cookies have inherent insecurity, and the Secure mark cannot provide definitive security guarantees.

8. Session

Besides storing user information in the user’s browser via cookies, session can also store information on the server side, which is more secure.

Session can be stored in files, databases, or memory on the server. Session can also be stored in in-memory databases such as Redis, which offers higher efficiency.

The process of using session to maintain user login status is as follows:

• When the user logs in, they submit a form containing username and password, placed in the HTTP request message.
• The server verifies the username and password; if correct, stores user information in Redis—the Key in Redis is called the “Session ID.”
• The response message’s Set-Cookie header field contains this Session ID; after receiving the response message, the client stores this cookie value in the browser.
• Subsequent requests from the client to the same server will include this cookie value; the server extracts the Session ID upon receipt, retrieves user information from Redis, and continues with business operations.

Security issues regarding Session ID should be noted—it must not be easily obtained by malicious attackers, meaning Session ID values should not be easily guessable. Additionally, Session IDs need frequent regeneration. In scenarios requiring extremely high security, such as fund transfers, besides using session to manage user status, users also need re-verification, such as re-entering passwords or using SMS verification codes, etc.

9. Browser Disabled Cookies

At this point, cookies cannot be used to save user information; only sessions can be used. Furthermore, Session IDs can no longer be stored in cookies; instead, URL rewriting technology is used to pass Session IDs as URL parameters.

10. Cookie Versus Session Selection

• Cookies can only store ASCII character strings, while sessions can store any type of data; therefore, session is preferred when considering data complexity.
• Cookies are stored in the browser and are easily viewed maliciously. If privacy data must be stored in cookies, the cookie value can be encrypted, then decrypted on the server.
• For large websites, if all user information is stored in sessions, the overhead is very substantial; therefore, storing all user information in sessions is not recommended.

Caching

1. Advantages

• Relieves server pressure.
• Reduces client resource retrieval latency: Caches are usually in memory, so reading cached data is faster. Furthermore, cache servers may be geographically closer than the origin server, such as browser caches.

2. Implementation Methods

• Have proxy servers perform caching.
• Have client browsers perform caching.

3. Cache-Control

HTTP/1.1 controls caching through the Cache-Control header field.

3.1 Prohibiting Caching

The no-store directive stipulates that no part of requests or responses can be cached.

Cache-Control: no-store

3.2 Forced Cache Confirmation

The no-cache directive stipulates that cache servers must first validate cache resource effectiveness with the origin server; only when the cache resource is valid can the cache respond to client requests.

Cache-Control: no-cache

3.3 Private Caches and Public Caches

The private directive stipulates resources as private caches, usable only by individual users, generally stored in user browsers.

Cache-Control: private

The public directive stipulates resources as public caches, usable by multiple users, generally stored in proxy servers.

Cache-Control: public

3.4 Cache Expiration Mechanism

The max-age directive appearing in request messages accepts the cache if the cache resource’s caching time is less than the time specified by this directive.

The max-age directive appearing in response messages indicates how long the cache resource is retained in the cache server.

Cache-Control: max-age=31536000

The Expires header field can also be used to inform cache servers when the resource expires.

Expires: Wed, 04 Jul 2012 08:26:05 GMT

• In HTTP/1.1, the max-age directive takes priority.
• In HTTP/1.0, the max-age directive is ignored.

4. Cache Validation

The ETag header field needs to be understood first; it is the unique identifier for resources. URLs cannot uniquely represent resources—for example, “http://www.google.com/” has Chinese and English versions as resources; only ETag can uniquely identify these two resources.

ETag: "82e22293907ce725faf67773957acd12"

The cached resource’s ETag value can be placed in the If-None-Match header; after receiving this request, the server compares whether the cached resource’s ETag value matches the latest resource ETag value. If consistent, the cached resource is valid, and the server returns 304 Not Modified.

If-None-Match: "82e22293907ce725faf67773957acd12"

The Last-Modified header field can also be used for cache validation; it is contained in response messages sent by the origin server, indicating the origin server’s last modification time of the resource. However, it is a weak validator because it only achieves one-second precision, so it typically serves as a backup to ETag. If this information exists in the response header field, clients can include If-Modified-Since in subsequent requests to validate caches. The server only returns the resource if it was modified after the given date/time, with status code 200 OK. If the requested resource has not been modified since that time, a 304 Not Modified response message without an entity body is returned.

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

Content Negotiation

Returns the most appropriate content through content negotiation, such as choosing whether to return a Chinese or English interface based on the browser’s default language.

1. Types

1.1 Server-Driven Type

The client sets specific HTTP header fields, such as Accept, Accept-Charset, Accept-Encoding, and Accept-Language; the server returns specific resources based on these fields.

It has the following problems:

• Servers find it difficult to know all information about the client’s browser.
• Information provided by clients is quite verbose (HTTP/2 protocol’s header compression mechanism alleviates this problem), and presents privacy risks (HTTP fingerprinting technology).
• Given resources need to return different display formats, shared cache efficiency is reduced, and server-side implementation becomes increasingly complex.

1.2 Proxy-Driven Type

The server returns 300 Multiple Choices or 406 Not Acceptable; the client selects the most appropriate resource from them.

2. Vary

Vary: Accept-Language

When using content negotiation, the cache can only be used when the content in the cache server meets content negotiation conditions; otherwise, the origin server should be requested for the resource.

For example, after a client sends a request containing the Accept-Language header field, the origin server’s response contains Vary: Accept-Language content. After the cache server caches this response, when the client next accesses the same URL resource and the Accept-Language matches the corresponding value in the cache, the cache is returned.

Content Encoding

Content encoding compresses the entity body, thereby reducing transmitted data volume.

Common content encodings include: gzip, compress, deflate, and identity.

Browsers send Accept-Encoding headers, containing supported compression algorithms along with respective priorities. The server selects one algorithm from them, uses it to compress the response message body, and sends the Content-Encoding header to inform the browser which algorithm was chosen. Since this content negotiation process selects resource display forms based on encoding types, the response message’s Vary header field should at least include Content-Encoding.

Range Requests

If network interruption occurs and the server only sends partial data, range requests enable the client to request only the unsent portion from the server, avoiding the need for the server to resend all data.

1. Range

Add the Range header field in the request message to specify the request range.

GET /z4d4kWk.jpg HTTP/1.1
Host: i.imgur.com
Range: bytes=0-1023

If the request succeeds, the server returns a response containing status code 206 Partial Content.

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/146515
Content-Length: 1024
…
(binary content)

2. Accept-Ranges

The response header field Accept-Ranges informs the client whether it can handle range requests; use bytes if it can, or none otherwise.

Accept-Ranges: bytes

3. Response Status Codes

• In successful request cases, the server returns status code 206 Partial Content.
• In cases where the request range exceeds bounds, the server returns status code 416 Requested Range Not Satisfiable.
• In cases where range requests are unsupported, the server returns status code 200 OK.

Chunked Transfer Coding

Chunked Transfer Encoding can split data into multiple blocks, allowing browsers to display pages progressively.

Multipart Object Collections

Multiple types of entities can be contained within one message body and sent simultaneously; each part is separated using delimiters defined by the boundary field, and each part can have header fields.

For example, uploading multiple forms can use the following method:

Content-Type: multipart/form-data; boundary=AaB03x

--AaB03x
Content-Disposition: form-data; name="submit-name"

Larry
--AaB03x
Content-Disposition: form-data; name="files"; filename="file1.txt"
Content-Type: text/plain

… contents of file1.txt …
--AaB03x--

Virtual Hosts

HTTP/1.1 uses virtual host technology, enabling one server to possess multiple domains, logically appearing as multiple servers.

Communication Data Forwarding

1. Proxy

Proxy servers accept client requests and forward them to other servers.

The main purposes of using proxies are:

• Caching
• Load balancing
• Network access control
• Access log recording

Proxy servers are divided into forward proxies and reverse proxies:

• Users are aware of the existence of forward proxies.

  

• Reverse proxies are generally located within internal networks, and users are unaware of them.

  

2. Gateway

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

3. Tunnel

Uses encryption methods such as SSL to establish a secure communication channel between the client and server.

VI. HTTPS

HTTP has the following security issues:

• Uses plaintext for communication; content may be eavesdropped on.
• Does not verify communication party identity; communication party identity may be impersonated.
• Cannot prove message integrity; messages may be tampered with.

HTTPS is not a new protocol; rather, it lets HTTP communicate with SSL (Secure Sockets Layer) first, then SSL communicates with TCP. In other words, HTTPS uses tunnels for communication.

Through SSL, HTTPS possesses encryption (prevents eavesdropping), authentication (prevents impersonation), and integrity protection (prevents tampering).

Encryption

1. Symmetric Key Encryption

Symmetric-key encryption uses the same key for both encryption and decryption.

• Advantages: fast computation speed.
• Disadvantages: cannot securely transmit the key to the communication party.

2. Asymmetric Key Encryption

Asymmetric key encryption, also known as public-key encryption, uses different keys for encryption and decryption.

Anyone can obtain the public key; after the communication sender obtains the receiver’s public key, encryption can be performed using the public key; the receiver decrypts the communication content after receipt using the private key.

Asymmetric keys can also be used for signing besides encryption. Since private keys cannot be obtained by others, the communication sender signs using their private key; the communication receiver decrypts the signature using the sender’s public key to determine whether the signature is correct.

• Advantages: public keys can be transmitted more securely to the communication sender.
• Disadvantages: slow computation speed.

3. Encryption Method Used By HTTPS

As mentioned above, symmetric key encryption has higher transmission efficiency but cannot securely transmit the secret key to the communication party. Asymmetric key encryption ensures transmission security, so we can use asymmetric key encryption to transmit secret keys to the communication party. HTTPS adopts a hybrid encryption mechanism, utilizing the scheme mentioned above:

• Uses asymmetric key encryption to transmit the secret key required by symmetric key encryption, thus ensuring security.
• After obtaining the secret key, uses symmetric key encryption for communication, thus ensuring efficiency. (The Session Key in the figure below is the secret key.)

Authentication

Uses certificates to authenticate communication parties.

Digital Certificate Authorities (CA, Certificate Authority) are trusted third-party institutions for both clients and servers.

Server operators submit applications for public keys to the CA; after confirming the applicant’s identity, the CA digitally signs the applied public key, then distributes this signed public key and binds it into a public key certificate.

During HTTPS communication, the server sends the certificate to the client. After obtaining the public key from the certificate, the client first verifies using digital signatures; if verification passes, communication can begin.

Integrity Protection

SSL provides message digest functionality for integrity protection.

HTTP also provides MD5 message digest functionality, but it is not secure. For example, after message content is tampered with, recalculating the MD5 value means the communication receiver cannot realize that tampering occurred.

HTTPS’s message digest functionality is secure because it combines encryption and authentication operations. Imagine encrypted messages—after being tampered with, recalculating the message digest is difficult because plaintext cannot be easily obtained.

Disadvantages of HTTPS

• Because encryption and decryption processes are required, speeds are slower.
• Requires payment for expensive certificate authorization fees.

VII. HTTP/2.0

HTTP/1.x Defects

HTTP/1.x simplicity comes at the cost of performance:

• Clients need multiple connections to achieve concurrency and shorten latency.
• Does not compress request and response headers, resulting in unnecessary network traffic.
• Does not support effective resource prioritization, causing low utilization of underlying TCP connections.

Binary Framing Layer

HTTP/2.0 splits messages into HEADERS frames and DATA frames; both are binary formats.

During communication, only one TCP connection exists, carrying any number of bidirectional data streams.

• Each data stream (Stream) has a unique identifier and optional priority information for carrying bidirectional information.
• Messages (Messages) are complete sequences of frames corresponding to logical requests or responses.
• Frames (Frames) are the smallest communication units; frames from different streams can be sent interleaved, then reassembled according to each frame header’s stream identifier.

Server Push

When HTTP/2.0 clients request a resource, related resources are sent to the client simultaneously, eliminating the need for subsequent requests. For example, when clients request the page.html page, the server sends related resources like script.js and style.css to the client simultaneously.

Header Compression

HTTP/1.1 headers carry a lot of information and must be resent repeatedly.

HTTP/2.0 requires clients and servers to simultaneously maintain and update a table containing previously seen header fields, avoiding duplicate transmissions.

Furthermore, HTTP/2.0 also uses Huffman coding to compress header fields.

VIII. HTTP/1.1 New Features

For detailed content, please refer to the text above.

• Long connections are default
• Supports pipelining
• Supports opening multiple TCP connections simultaneously
• Supports virtual hosts
• Adds status code 100
• Supports chunked transfer coding
• Adds cache processing instruction max-age

IX. GET and POST Comparison

Purpose

GET is used to retrieve resources, while POST is used to transmit entity bodies.

Parameters

Both GET and POST requests can use additional parameters, but GET parameters appear as query strings in the URL, while POST parameters are stored in the entity body. One should not believe POST parameters are more secure simply because they are stored in the entity body, since packet capture tools (like Fiddler) can still view them.

Because URLs only support ASCII characters, GET parameters containing characters such as Chinese must be encoded first. For example, 中文 converts to %E4%B8%AD%E6%96%87, and spaces convert to %20. POST parameters support standard character sets.

GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1

POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2

Security

Secure HTTP methods do not change server state; they are read-only.

The GET method is secure, while POST is not, because POST’s purpose is to transmit entity body content; this content may be form data uploaded by users; after successful upload, the server may store this data in a database, thus changing state.

Secure methods besides GET also include: HEAD, OPTIONS.

Insecure methods besides POST also include: PUT, DELETE.

Idempotency

Idempotent HTTP methods produce the same effect whether executed once or consecutively multiple times; server state is identical. In other words, idempotent methods should not have side effects (except for statistical purposes).

All safe methods are also idempotent.

Under correct implementation conditions, GET, HEAD, PUT, and DELETE methods are idempotent, while the POST method is not.

GET /pageX HTTP/1.1 is idempotent; calling it consecutively multiple times produces the same result received by the client:

GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1

POST /add_row HTTP/1.1 is not idempotent; calling it multiple times adds multiple record rows:

POST /add_row HTTP/1.1   → Adds a 1st row
POST /add_row HTTP/1.1   → Adds a 2nd row
POST /add_row HTTP/1.1   → Adds a 3rd row

DELETE /idX/delete HTTP/1.1 is idempotent, even if different requests receive different status codes:

DELETE /idX/delete HTTP/1.1   → Returns 200 if “idX” exists
DELETE /idX/delete HTTP/1.1   → Returns 404 as it just got deleted
DELETE /idX/delete HTTP/1.1   → Returns 404

Cacheable

To cache responses, the following conditions must be met:

• The HTTP method in the request message itself must be cacheable, including GET and HEAD, but PUT and DELETE are not cacheable; POST is generally not cacheable in most cases.
• The response message’s status code must be cacheable, including: 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501.
• The response message’s status code must be cacheable, including: 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501.
• The response message’s Cache-Control header field does not specify no caching.

XMLHttpRequest

To illustrate another distinction between POST and GET, XMLHttpRequest must first be understood:

XMLHttpRequest is an API that provides functionality for transmitting data between client and server. It offers a simple way to retrieve data through URLs without refreshing the entire page. This allows web pages to update only part of the page without disturbing the user. XMLHttpRequest is extensively used in AJAX.

• When using XMLHttpRequest’s POST method, browsers first send headers then send data. However, not all browsers do this—for example, Firefox does not.
• The GET method sends headers and data simultaneously.

References

• Ueno Nobushi. Illustrated HTTP [M]. Posts & Telecom Press, 2014.
• HTTP
• Introduction to HTTP/2
• htmlspecialchars
• Difference Between File URI and URL in Java
• How to Fix SQL Injection Using Java PreparedStatement and CallableStatement
• 浅谈 HTTP 中 Get 与 Post 的区别
• Are “http://” and “www” Really Necessary?
• HTTP (HyperText Transfer Protocol)
• Web-VPN: Secure Proxies With SPDY and Chrome
• File:HTTP persistent connection.svg
• Proxy Server
• What Is This HTTPS/SSL Thing and Why Should You Care?
• What Is SSL Offloading?
• Sun Directory Server Enterprise Edition 7.0 Reference—Key Encryption
• An Introduction to Mutual SSL Authentication
• The Difference Between URLs and URIs
• Cookie 与 Session 的区别
• Cookie 和 Session 有什么区别
• Cookie/Session 的机制与安全
• HTTPS 证书原理
• What Is the Difference Between a URI, a URL, and a URN?
• XMLHttpRequest
• XMLHttpRequest (XHR) Uses Multiple Packets for HTTP POST?
• Symmetric vs. Asymmetric Encryption—What Are [the] Differences?
• Web 性能优化与 HTTP/2

(This post is a machine-made, human-reviewed, and authorized translation of xuxueli.com/­blog/­?blog=network/­http.)