HTTP details – Getting started

preface

The outline

After reading this article, I hope you understand:

• What are the security risks of HTTP communication?
• What are the differences between HTTP versions?
• How HTTPS improves HTTP What are the problems?
• How does HTTPS work?

What is HTTP?

Summary: HTTP is a standard for client end (user) and server end (Web site) requests and responses. Typically, an HTTP client initiates a request to create a TCP connection to a specified port on the server (default: port 80). The HTTP server listens for client requests on that port. Once a request is received, the server returns a status to the client, such as “HTTP/1.1 200 OK”, along with what is returned, such as the requested file, error message, or other information

The characteristics of HTTP

• None connection: The server processes only one request at a time. After the server processes the request and receives the reply from the user, the server disconnects from the client, saving the transmission time
• Stateless: Stateless means that the protocol has no memory for processing things. The communication state between the request and response is not saved, and the absence of state means that if the previous information is needed for subsequent processing, it must be retransmitted. The stateless protocol solution is as follows: 1. Use cookies. 2
• Simple and fast: When a client requests a service from the server, it only needs to send the request method and path. Because HTTP protocol is simple, the communication speed is relatively fast

HTTP shortcomings

• Communications are transmitted in plaintext (not encrypted) and the content may be eavesdropped
• Do not verify the identity of the correspondence party and may encounter camouflage
• Packet integrity cannot be proved and may be tampered with

Consider: How can hackers exploit these weaknesses, and how can we defend against them?

[2] HTTP packets

HTTP packets are information used for HTTP interaction and can be classified into two types: request packets and response packets. HTTP packets can be roughly divided into a header and a packet body, which are usually separated by blank lines. The header is usually used to process the content and attributes of the server – or client-side processing request or response.

2.1 HTTP Request Packets

An HTTP request header consists of the header (request line + request header), blank line (CR+LF), and packet body (request body) in the following format

POST https://example.com/comments HTTP / 1.1Line # request
content-type: application/json   # request header
# blank line (CR + LF)
{
    "name": "sample".# request body
    "time": "Wed, 21 Oct 2015 18:27:50 GMT"
}
Copy the code

2.1.1 request line

Let’s look at the composition of the request line: request method (eight), request address, protocol version, separated by Spaces.

POST https://example.com/comments HTTP / 1.1

Request method

The HTTP/1.1 protocol defines eight methods (also known as “actions”) to manipulate a given resource in different ways: POST, GET, PUT, DELETE, OPTIONS, HEAD, TRACE, and CONNECT. Only POST/GET/ is defined in HTTP1.0

The method name	instructions
GET	Emitted to the specified resourceAccording toRequests, using the GET method, should only be used to read data, not produce itSide effectsThe operation of the
POST	Specify the resource to submit data and request the server to process it (for example, submit a form or upload a file). The data is contained in the request text. This request may create a new resource or modify an existing resource, or both
PUT	Uploads its latest content to the specified resource location
DELETE	Requests the server to remove the resource identified by request-URI
OPTIONS	Causes the server to return all HTTP request methods supported by the resource. with*Instead of the resource name, send an OPTIONS request to the Web server to test whether the server functions properly
HEAD	Like the GET method, a request is made to the server for a specified resource, except that the server does not return the text portion of the resource. The advantage of this method is that you can retrieve information about the resource (raw information, or metadata) without having to transmit the entire content
TRACE	Displays requests received by the server, mainly for testing or diagnostics
CONNECT	Reserved in HTTP/1.1 for proxy servers that can change connections to channel mode. Typically used for links to SSL encrypted servers (via an unencrypted HTTP proxy server)

Request address URI

The Uniform Resource Identifier (URI) is simply a Uniform Resource Identifier that distinguishes different resources on the Internet. The format is as follows: Scheme :// user: password@host :port path? query #fragemnt

https://juejin.cn/editor/drafts/6899443200332103693
Copy the code

field	describe
scheme	Represents the protocol name, such as HTTP, HTTPS, file, etc. It must be followed by ://.
user:passwd@	Indicates the user information used to log in to the host. However, it is not recommended and is not commonly used.
host:port	Indicates the host name and port. Host names come in three forms: domain nameswww.tutu.com;, using the IPv4 192.168.0.1 address name,
path	Represents the request path, marking the location of the resource.
query	Represents a query parameter of the form key=val, separated by ampersand.
fragment	Represents an anchor point within the resource located by the URI that the browser can jump to.

Here’s an example:

https://www.baidu.com/s?wd=HTTP&rsv_spt=1
Copy the code

In this URI, HTTPS is the scheme part, www.baidu.com is the host:port part (note that HTTP and HTTPS default ports are 80 and 443 respectively), /s is the path part, and wd=HTTP&rsv_spt=1 is the query part. Specific values of location are as follows:

{
  "href": "https://www.baidu.com/s?wd=HTTP&rsv_spt=1",
  "origin": "https://www.baidu.com",
  "protocol": "https:",
  "host": "www.baidu.com",
  "hostname": "www.baidu.com",
  "port": "",
  "pathname": "/s",
  "search": "?wd=HTTP&rsv_spt=1",
  "hash": ""
}
Copy the code

URI encoding UrIs can only use ASCII encoding (see front end encoding for details), characters other than ASCII are not supported to display, and some symbols are delimiters, which can cause parsing errors if left untreated.

Therefore, URIs introduce an encoding mechanism that converts all non-ASCII characters and delimiters into hexadecimal byte values, followed by a %. For example, space is escaped to %20, and ternary is escaped to %E4%B8%89%E5%85%83.

The escape escape function is an attribute of the global object. Special characters such as @*_+-./ are excluded. The hexadecimal format value of the character, represented by a 2-bit transition sequence: %xx when the value is less than or equal to 0xFF. If greater than, use a 4-bit sequence :%uxxxx.

EncodeURI vs encodeURIComponent They all have in common the encoding of URIs, but the encoding ranges are different.

• 1, if it is only an encoding string, and has no relation to the URI, then useescape
• 2. If you need to encode the entire URI and then need to use the URI, use theencodeURI
• 3. When you need to encode parameters in the URI, thenencodeURIComponentIs the best way

Simple understanding: The effect of encodeURI on Japanese and Korean Characters. For special characters in UR (; /? :@&=+$,#) does not handle, encodeURIComponent does not handle URI special characters (; /? :@&=+$,#) to convert them to their ASCII counterparts

Protocol version

Used to specify the HTTP protocol version used for current communication. I’m not going to expand and follow up for space reasons

2.1.2 request header

The request header can be used to pass some additional information in the format: key: value, note that there is a space after the colon:

2.1.3 request body

Request body (also called request body) is a request parameter in POST request mode. It is stored in the form of key = value. Multiple request parameters are connected with &. If a request has a body, the Content-Length attribute in the request header records the Length of the body

2.2 HTTP Response Packets

HTTP response packets are divided into three parts: response status line, response header, and response body

HTTP / 1.1 200 ok# Response status line
Content-Type: application/json  # various header fields
Server: example.com   
# blank line (CR + LF)
{
    "code": 0."msg": "success"."data": {
        "username": "username"}}Copy the code

2.2.1 Response status line

The response status line consists of three parts: the HTTP version, the status code, and a simple phrase that explains the status code, separated by Spaces, such as:

HTTP/1.1 100 Continue
HTTP/1.1 200 Ok
HTTP/1.1 204 No Content
HTTP/1.1 404 Not Fund
Copy the code

The general status code is as follows:

Status code	describe
1xx	The delegate request has been accepted and needs to continue processing
2xx	The request was successful, and the desired response header or data body is returned with this response
3xx	redirect
4xx	Error caused by client
5xx	Error caused by server

See appendix for details about HTTP status codes and the corresponding scenarios for each status code

2.2.2 response headers

[3] HTTP protocol version

HTTP / 1.0 3.1

This version:

• The request modes include POST, DELETE, PUT, and HEAD
• Added the concept of request headers and response headers, specifying HTTP protocol version numbers in communication, and other meta information (such as: status code, permissions, cache, content encoding)
• Expanded the transmission format, pictures, audio and video resources, binary and so on can be transmitted

In this release, the request and response meta-information has been extended, so that clients and servers have more access to all the information about the current request, so that they can better and faster process the request-related content.

HTTP / 3.2 1. X

HTTP 1.1 was released six months after the 1.0 release, improving on the 1.0 release. There are also many Internet projects that provide services based on HTTP 1.1.

* * * * characteristics

• Long Connection: The Connection field is added and the keep-alive value can be set to keep the Connection open
• Pipelining: Based on the long connection above, pipelining can continue to send subsequent requests without waiting for the first response, but the response is returned in the order requested
• Cache processing: Added field cache-control
• Breakpoint transmission

3.2.1 Keep-alive Persistent Connection

Each HTTP communication in HTTP1.0 disconnects a TCP connection. Thus, a TCP connection is established and disconnected for each request, which increases the communication overhead. To solve this problem, persistent connections are enabled in HTTP /1.1 with the default Connection:keep-alive to reduce the overhead caused by repeated TCP establishment and disconnection and reduce the load on the server side.

3.2.2 pipelines

Based on the long connection (TCP connection is not disconnected), we compare the response results of pipelined request with or without

Request 1 > Response 1 --> Request 2 > Response 2 --> Request 3 > Response 3 Response Request 1 --> Request 2 --> Request 3 --> Response 1 --> Response 2 --> Response 3 response 1 --> Response 2 --> Response 3Copy the code

In the case of persistent connections, pipelining enables simultaneous concurrency of multiple requests without waiting for one response after another. Although pipelined, multiple requests can be sent at once, but the response is still returned sequentially, still does not solve the problem of queue head blocking.

3.2.3 Resumable Data On a Breakpoint

When uploading or downloading resources, divide the resources into multiple parts and upload or download them separately. If a network fault occurs, you can continue to upload or download the resources from the places where the resources have been uploaded or downloaded, instead of starting from the beginning to improve efficiency

HTTP / 2.0 3.3

HTTP2 significantly improves web performance compared to http1.x, and further reduces network latency on the basis of full compatibility with HTTP1.1. For front-end developers, it undoubtedly reduces front-end optimization. Features:

• Binary framing
• Multiplexing: Sending requests and responses simultaneously over a shared TCP connection
• The head of compression
• Server push: The server can push additional resources to the client without an explicit request from the client

3.3.1 Binary framing

The parsing of HTTP 1.x is based on text. After HTTP 2, all transmitted information is divided into smaller messages and frames, and they are encoded in binary format to improve transmission efficiency.

3.3.2 Multiplexing

Requests and responses are sent simultaneously on the basis of shared TCP links. Based on binary framing, all accesses under the same domain name are routed through the same TCP connection. HTTP messages are decomposed into separate frames and sent out of order, and the server reassembles the messages according to the identifier and header.

3.3.3 Header compression

Because HTTP is stateless, each request requires header information to identify the relevant information of the request, so many duplicate information will be transmitted. As the number of requests increases, the consumption of resources will slowly accumulate. Therefore, HTTP 2 can maintain a header dictionary to update header information and reduce the resources occupied by header information transmission. For details, see HTTP/2 Header compression technology.

[4] HTTPS

HTTPS is a network protocol that uses SSL and HTTP to encrypt transmission and authenticate identities. It is more secure than HTTP. The HTTPS protocol basically relies on TLS/SSL. TLS/SSL relies on three basic algorithms: hash function, symmetric encryption, and asymmetric encryption. How HTTTPS improves secure transport against HTTP’s shortcomings:

• 1. Use asymmetric encryption to implement identity authentication and session key negotiation
• 2. Use session key based on symmetric encryption algorithm to encrypt data
• The packet integrity cannot be proved and may be tampered with. ===> 3. Verify the integrity of the information based on the hash function

4.1 Encryption Mode

4.1.1 Symmetric Key Encryption

Encryption and decryption using the same key is called shared key encryption, also known as symmetric key encryption. That is, the client and server share a key to encrypt messages. When a client sends a request, it encrypts the message with a key. After receiving the message, the server decrypts it with the key.

Disadvantages: Symmetric encryption ensures message confidentiality, but the client and server use the same key, if there is a middleman or an attacker in the process of transmission. The key could fall into the hands of an attacker, making it pointless to encrypt messages.

The common symmetric encryption algorithms include DES, AES, and IDEA

4.1.2 Asymmetric Key Encryption

Asymmetric key Encryption uses a pair of asymmetric keys. One is called a private key and the other is called a public key. A private key can only be owned by oneself, while a public key can be accessed by anyone.

• When a client sends a message, it encrypts it using a public key,
• When the server receives the message, it decrypts it using the private key.

Disadvantages:

• The public key is available to anyone and can be tampered with by an intermediary and returned to the client. Asymmetric encryption requires the sender to encrypt messages with public keys. But public keys are available to anyone, even middlemen. Although the middleman does not know what the private key of the receiver is, he can intercept the public key of the sender, generate another public key or tamper with the public key and send it to the receiver.
• Encryption and decryption efficiency is low. Asymmetric encryption is more complex to handle than symmetric encryption, which leads to lower efficiency.

Currently, common asymmetric encryption algorithms include RSA, DSA, DH, etc.

Hybrid encryption mechanism

A digital signature

Digital signature is the application of asymmetric encryption and digital digest. It encrypts the digest information with the sender’s private key and sends the original text to the receiver together. The receiver can decrypt the encrypted digest only with the sender’s public key, and then use the Hash function to generate a digest of the received text and compare it with the decrypted digest. If they do, the message is complete. Otherwise, the information has been modified. Therefore, the digital signature can verify the integrity of the information.

Benefits: A digital signature is a special encryption check code attached to a packet. There are two benefits to using a digital signature.

• 1. The signature confirms that the message is signed and sent by the sender, since no one can impersonate the sender’s signature.
• 2. Signature can determine the integrity of the message and prove that the data has not been tampered with.

The digital certificate also includes the public key of the object, and a description of the object and the signature algorithm used. Anyone can create a digital certificate, but not everyone can get the right to issue the certificate by vouch for the certificate information and issue the certificate with its private key.

Digital signature generation process (sender) : Plaintext > Hash operation > Digest > Private key encryption > Digital signature. Digital signature verification process (receiver) : Original + Digital signature -> (Public key decrypts digital signature) Summary information vs (original text) Hash operation –>

The digital certificate

Composition: Certificate issuer CA, certificate validity period, certificate owner, public key, and signature

Communication mechanism

The process can be divided into three stages:

• In obtainingPublic key certificateStep: After receiving the public key certificate from the server, the client uses the public key of the digital certification authority to verify the digital signature in the public key certificate to verify the authenticity of the public key certificate.
• In the exchangeThe session keyStep: Using asymmetric encryption, the client uses the public key in the public key certificate to encryptSession keyAnd the other party decrypts it with its private keySession keyIn order to ensure that the exchanged key is secure, symmetric encryption (The session keys) to communicate.
• Normal packet communication: The server and client use the same packetThe session keys(Symmetric encryption and release mode) Encrypts and decrypts the packet body.

The detailed process is as follows:

• 1. The client sends an HTTPS request to the server. The Client knows that it needs to connect to port 443 (the default) of the Server.
• 2. The server returns the pre-configured public key certificate (the certificate applied from the authoritative CA) to the client.
• 3. After receiving the public key certificate, the client verifies the digital signature with the public key of the CA to verify the authenticity of the public key certificate of the server.
• 4. The client generates a temporary session key with the pseudo-random number generator, encrypts the session key with the public key of the certificate returned by the server, and sends the session key to the server.
• 5. After receiving the message, the server decrypts the message with its own private keyThe session key. At this point, both Client and Server hold the sameThe session key
• 6. After that, the client and server start HTTPS communication.
• 7. Server useThe session keyEncrypt plaintext A and send it to the Client. The Client to useThe session keyDecrypt the ciphertext of the response to obtain plaintext A.
• 8. The Client sends an HTTPS request againThe session keyEncrypts the “plaintext B” of the request, which the Server then usesThe session keyDecrypt the ciphertext and get “plaintext B”.

Is HTTPS secure?

How does HTTPS ensure website security?

From the following three aspects:

• 1. Authenticate the user or server to ensure that it is sent to the correct client or server
• 2. Encrypt data to prevent data from being stolen
• 3. Maintain data integrity to ensure that data will not be tampered with during transmission

The following is the overall architecture of HTTPS. Nowadays, HTTPS basically uses TSL, so SSL in the figure below should be changed to SSL/TSL because it is more secure. There are two stages:

• 1. SSL relies on the digital certificate to establish a secure session in the full handshake phase (obtaining the session secret key)
• 2. During transmission, SSL encrypts packets using the session key obtained in the previous step

How do I prove that the public key received by the browser must be the public key of the web site? Or how to verify a digital certificate?

Are CA certificates secure?

The CA certificate is used to prevent tampering and does not ensure that the ciphertext can be read by eavesdropping.

• Suppose the middleman tampered with the original text of the certificate. Since he did not have the private key of the CA institution, he could not get the encrypted signature at this time and could not tamper with the signature accordingly. After receiving the certificate, the browser finds that the original text is inconsistent with the decrypted signature value. In this case, the certificate has been tampered and cannot be trusted. In this way, information is stopped from being transmitted to the server to prevent information leakage to the middleman.

Why do I need to hash a digital signature once?

Asymmetric encryption is inefficient, and the certificate information is usually long and time-consuming. The hash results in a fixed length of information (for example, md5 hash results in a fixed 128-bit value), which makes encryption and decryption much faster

Could a shared key be intercepted by a middleman?

Must HTTPS first handshake transfer keys at the SSL/TLS layer on every request?

Obviously, the key transfer process is very time-consuming for each request, so how to achieve only one transfer? You can just use session. The server maintains a session ID for each browser (or client software) and sends it to the browser during the TSL handshake phase. After the browser generates the key and sends it to the server, the server stores the key in the corresponding session ID. After that, the browser will carry the Session ID with each request. The server finds the corresponding key according to the session ID and decrypts and encrypts the key. In this way, it is unnecessary to make and transfer the key every time

[V] HTTP request process

expand

If there are many omissions or unclear explanations of HTTP in this article, it is recommended to purchase the illustrated HTTP book for more details

The appendix

The HTTP/1.1 specification defines the following 47 header fields. According to the actual routes are divided into four categories:

• Generic header field: Indicates the header field used by both request and response packets
• Request header field: Indicates the header field used by the client to send request packets to the server, which provides additional information about the request, client information, and priority information about the response content
• Response header field: Indicates the header used when the server sends a response packet to the client. It supplements the additional content of the response and requires the client to attach additional content
• Entity head field: For the header used in the entity part of the request message and response message, the update time of the resource content and information about the entity are added

Table 1: General Header Fields

Header	explain	The sample
Cache-Control	Control the cache
Connection	Connection management, hop – by – hop header
Upgrade	It can be used to check whether HTTP and other protocols are available and communicate with a higher version
via	Proxy server information can be used to trace the transmission paths of request and response packets between clients and servers. It can also be used to avoid request loops, often in conjunction with trace requests.
Transfor-Encoding	Transmission code format of the packet body
Trailer will specify in advance which header fields are recorded after the message body, which can be applied in block transfer codes
Pragma	Message instructions, which are legacy fields, exist only for compatibility
Date	Date when the packet is created

Table 2: Request header fields

Header	explain	The sample
Accept	Specifies the type of content that the client can receive	Accept: text/plain, text/html
Accept-Charset	A set of character encodings acceptable to the browser.	Accept-Charset: iso-8859-5
Accept-Encoding	Specifies the type of web server content compression encoding that the browser can support.	Accept-Encoding: compress, gzip
Accept-Language	Browser acceptable language	Accept-Language: en,zh
Accept-Ranges	You can request one or more subscope fields of a web page entity	Accept-Ranges: bytes
Authorization	HTTP authorization certificate	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control	Specify the caching mechanism that requests and responses follow	Cache-Control: no-cache
Connection	Indicates whether a persistent connection is required. (HTTP 1.1 makes persistent connections by default)	Connection: close
Cookie	When an HTTP request is sent, all cookie values stored under the domain name of the request are sent to the Web server.	Cookie: $Version=1; Skin=new;
Content-Length	The content length of the request	Content-Length: 348
Content-Type	MIME information that corresponds to the entity being requested	Content-Type: application/x-www-form-urlencoded
Date	The date and time the request was sent	Date: Tue, 15 Nov 2010 08:12:31 GMT
Expect	The specific server behavior requested	Expect: 100-continue
From	Email address of the user who made the request	From: [email protected]
Host	Specifies the domain name and port number of the requested server	Host: www.zcmhi.com
If-Match	This is valid only if the request content matches the entity	If – the Match: “737060 cd8c284d8af7ad3082f209582d”
If-Modified-Since	If the part of the request is modified after the specified time, the request succeeds; if it is not modified, the 304 code is returned	If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
If-None-Match	If the content has not changed, the 304 code is returned with the Etag sent by the server. The Etag is compared with the Etag returned by the server to determine whether it has changed	If None – Match: “737060 cd8c284d8af7ad3082f209582d”
If-Range	If the entity has not changed, the server sends the missing part of the client, otherwise sends the whole entity. The parameter is also Etag	If – Range: “737060 cd8c284d8af7ad3082f209582d”
If-Unmodified-Since	The request succeeds only if the entity has not been modified after the specified time	If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT
Max-Forwards	Limit the amount of time messages can be sent through proxies and gateways	Max-Forwards: 10
Pragma	Used to contain implementation-specific instructions	Pragma: no-cache
Proxy-Authorization	Certificate of authorization to connect to the agent	Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range	Only a portion of the entity is requested, specifying scope	Range: bytes=500-999
Referer	The address of the previous web page, followed by the current requested web page, is the incoming path	Referer: www.zcmhi.com/archives/71…
TE	The client is willing to accept the transmission code and notifies the server to accept the end plus header message	TE: trailers,deflate; Q = 0.5
Upgrade	Specify some transport protocol to the server for the server to convert (if supported)	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/ X11
User-Agent	User-agent contains the information about the User that sends the request	The user-agent: Mozilla / 5.0 (Linux; X11)
Via	Notification intermediate gateway or proxy server address, communication protocol	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning	Warning information about message entities	Warn: 199 Miscellaneous warning

Table 3: Response header fields

Header	explain	The sample
Accept-Ranges	Indicates whether the server supports scoped requests and what type of segmented requests	Accept-Ranges: bytes
Age	Estimated time from the original server to proxy cache formation (in seconds, non-negative)	Age: 12
Allow	A valid request for a network resource. If not allowed, 405 is returned	Allow: GET, HEAD
Cache-Control	Tell all caching mechanisms whether they can cache and what type	Cache-Control: no-cache
Content-Encoding	The type of returned content compression encoding supported by the Web server.	Content-Encoding: gzip
Content-Language	The language of the response body	Content-Language: en,zh
Content-Length	The length of the response body	Content-Length: 348
Content-Location	Request an alternate address for alternate resources	Content-Location: /index.htm
Content-MD5	Returns the MD5 check value of the resource	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range	The byte position of this part in the entire return body	Content-Range: bytes 21010-47021/47022
Content-Type	Returns the MIME type of the content	Content-Type: text/html; charset=utf-8
Date	The time when the original server message was sent	Date: Tue, 15 Nov 2010 08:12:31 GMT
ETag	The current value of the entity label of the request variable	ETag: “737060 cd8c284d8af7ad3082f209582d”
Expires	The expiration date and time of the response	Expires: Thu, 01 Dec 2010 16:00:00 GMT
Last-Modified	The last modification time of the requested resource	Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
Location	Used to redirect the recipient to the location of the non-requested URL to complete the request or to identify a new resource	Location: www.zcmhi.com/archives/94…
Pragma	This includes implementing specific instructions that can be applied to any recipient on the response chain	Pragma: no-cache
Proxy-Authenticate	It indicates the authentication scheme and the parameters that can be applied to the URL of the broker	Proxy-Authenticate: Basic
refresh	Applied to redirects or a new resource is created, redirects after 5 seconds (proposed by Netscape and supported by most browsers)	Refresh: 5; url=www.atool.org/httptest.ph…
Retry-After	If the entity is temporarily unavailable, notify the client to try again after the specified time	Retry-After: 120
Server	Name of the Web server software	Server: Apache / 1.3.27 (Unix) (Red Hat/Linux)
Set-Cookie	Set the Http cookies	Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
Trailer	Indicates that the header field exists at the end of the block transfer code	Trailer: Max-Forwards
Transfer-Encoding	File transfer coding	Transfer-Encoding:chunked
vary	Tell the downstream proxy whether to use a cached response or request from the original server	Vary: *
Via	Tell the proxy client where the response is sent	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning	Alerts entities to possible problems	Warning: 199 Miscellaneous warning
WWW-Authenticate	Indicates the authorization scheme that the client requesting entity should use	WWW-Authenticate: Basic

Table 4 Entity header fields

Header	explain
Allow	Resources can support HTTP request methods
Content-Encoding	Entity encoding formats include GZIP, COMPRESS, Deflate and Identity
Content-Language	The resource language of the entity
Content-Location	This field replaces the URI of the resource. Different from Location, this field indicates the URI of the resource returned by the packet subject
Content-Length	Entity size (bytes)
Content-Type	Physical media types
Content-MD5	Summary of entity packets. This field cannot verify whether the content is tampered
Content-Range	For a scope request, the client can be told which part of the entity returned as a response complies with the scope request
Last-Modified	Resource The last modified resource
Expires	Expired resources for entity principals

Responses 部分 | Http Response code

Status code	Explain the phrase	describe	Usage scenarios
200	OK
204	No Content	It has the same meaning as 200	There is no body data after the response header
206	Partial Content	Part of the content	Application scenarios include HTTP block download and resumable upload
301	Moved Permanently	Permanent redirect, indicating that the resource has been assigned a new URL.	For example, if your site is upgraded from HTTP to HTTPS and the previous site is no longer used, you should return to 301. By default, the browser will cache optimizer and automatically return to the redirected address on the second visit
302	Found	Temporary redirect: a resource is temporarily assigned a new URL and is expected to be accessed using the new URI	Unlike 301, browsers do not do cache optimization
303	See Other	Indicates that another URL exists for the resource and the resource should be obtained using the GET method
307	Temporary Redirect	Temporary redirect: indicates that the resource has been temporarily assigned a new URL
304	Not Modified	Indicates that the server allows access to the resource, but the request condition is not met because of an occurrence
400	Bad Request	Syntax errors exist in the request packet. Procedure
401	Unauthorized	Indicates that the sent request requires authentication information authenticated through HTTP
403	Forbidden	Indicates that access to the requested resource was denied by the server
404	Not Found	The requested resource was not found on the server
500	Internal Sever Error	An error occurred on the server side while executing the request
503	Service Unavailable	The server is temporarily overloaded or is down for maintenance and cannot process requests