HTTP request headers - the basics you need to remember

Introduction

Usually HTTP messages include request messages from the client to the server and response messages from the server to the client. The client sends a request to the server, and the request header contains the request method, URI, protocol version, and a message structure similar to MIME containing request modifiers, client information, and content. The server responds with a status line, and the corresponding content includes the version of the message protocol, success or error code, plus server information, entity meta information, and possible entity content.

The HTTP protocol defines many methods for interacting with the server. The four most basic methods are GET, POST, PUT, and DELETE. A URL address is used to describe a resource on the Internet, and GET, POST, PUT, and DELETE in HTTP correspond to the four operations of querying, modifying, adding, and deleting this resource. The most common ones are GET and POST. GET is generally used to obtain/query resource information, while POST is generally used to update resource information.

1. HTTP header information interpretation

HTTP header fields include general header, request header, response header and entity header. Each header field consists of a domain name, a colon (:) and a domain value.

• Common header: It is a header that can be used by both clients and servers. It can provide some very useful common functions between clients, servers and other applications, such as Date header.
• Request headers: are specific to request messages and provide the server with some additional information, such as what type of data the client wants to receive, such as the Accept header.
• Response header: It is convenient for the client to provide information, for example, what type of server the client is interacting with, such as the Server header.
• Entity header: refers to the header used to deal with the entity body. For example, the entity header can be used to describe the data type of the entity body, such as the Content-Type header.

1. HTTP General Headers

Common header fields include header fields supported by both request and response messages. Common header fields include cache headers Cache-Control, Pragma and informational headers Connection, Date, Transfer-Encoding, Update, and Via.

(1) Cache-Control

Cache-Control specifies the cache mechanism followed by requests and responses. Setting Cache-Control in a request message or a response message does not modify the cache processing process in the other message processing process. The cache instructions in the request include no-cache, no-store, max-age, max-stale, min-fresh, and only-if-cached. The instructions in the response message include public, private, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, and max-age. The meanings of the instructions in each message are as follows:

• no-cache: indicates that the request or response message cannot be cached. In fact, it can be stored in the local cache area, but the cache cannot provide it to the client before verifying the freshness with the original server.
• no-store: The cache should remove all traces of the document from storage as quickly as possible, as it may contain sensitive information.
• max-age: The cache cannot return documents that have been cached for longer than the specified seconds of max-age. If it does not exceed the specified seconds, the browser will not send the corresponding request to the server, and the data will be returned directly from the cache; after this period of time, the server will decide whether to return new data or continue to provide it from the cache. If the max-stale directive is also sent at the same time, the usage period may exceed its expiration time.
• min-fresh: The document must remain fresh for at least the specified number of seconds in the future, and cache objects whose freshness lifetime is greater than the sum of their current Age and min-fresh values ​​are accepted.
• max-stale: indicates that the client can receive expired response messages. If the max-stale message value is specified, the client can receive response messages that are expired but within the specified value.
• only-if-cached: The client will get a copy only if there is a copy in the cache.
• Public: Indicates that the response can be cached by any cache and can be used to respond to any user.
• Private: Indicates that the entire or partial response message for a single user cannot be processed by the shared cache and can only be used to respond to the user who previously requested the content.

(2) Pragma

The Pragma header field is used to contain implementation-specific instructions, the most commonly used of which is Pragma: no-cache. In the HTTP/1.1 protocol, its meaning is the same as Cache-Control: no-cache.

(3) Connection

Connection indicates whether a persistent connection is required. If the Servlet sees the value here as "Keep-Alive" or sees that the request uses HTTP 1.1 (HTTP 1.1 uses a persistent connection by default), it can take advantage of the persistent connection and significantly reduce the time required for downloading when the page contains multiple elements (such as applets, pictures). To achieve this, the Servlet needs to send a Content-Length header in the response. The simplest way to implement this is to first write the content to a ByteArrayOutputStream, and then calculate its size before officially writing the content.

• Close: Tells the web server or proxy server to disconnect after completing the response to this request and not to wait for subsequent requests from this connection.
• Keepalive: Tells the web server or proxy server to maintain the connection after completing the response to the current request and wait for subsequent requests from this connection.
• Keep-Alive: If the browser requests to maintain the connection, this header indicates how long (in seconds) you want the WEB server to maintain the connection, such as Keep-Alive: 300.

(4) Date

The Date header field indicates the time when the message was sent. The server response must include this header because the cache uses it when evaluating the freshness of the response. The time description format is defined by RFC822. For example, Date:Mon, 31 Dec 2001 04:25:57 GMT. The time described by Date indicates the Universal Standard Time. To convert it to the local time, you need to know the time zone where the user is located.

(5) Transfer-Encoding

The web server indicates how it encodes the response message body (not the objects in the message body), such as whether it is chunked. For example: Transfer-Encoding: chunked

(6) Upgrade

It can specify another, possibly completely different, protocol. For example, an HTTP/1.1 client can send an HTTP/1.0 request to a server that contains an Update header with a value of "HTTP/1.1" so that the client can test whether the server also uses HTTP/1.1.

(7) Via

List the proxy servers that the responses from the client to the OCS or vice versa pass through, and what protocols (and versions) they use to send the requests.

When the client request reaches the first proxy server, the server will add a Via header to the request it sends and fill in its own relevant information. When the next proxy server receives the request from the first proxy server, it will copy the Via header of the previous proxy server's request in its own request and add its own relevant information to the end. And so on. When OCS receives the request from the last proxy server, it checks the Via header and knows the route the request has taken. For example: Via: 1.0 236-81.D07071953.sina.com.cn:80 (squid/2.6.STABLE13)

2. HTTP Request Header

The request header is used to indicate who or what is sending the request, where the request originated from, or the client's preferences and capabilities. The server can try to provide a better response to the client based on the client information given in the request header. The request header field may contain the following fields: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Authorization, From, Host, If-Modified-Since, If-Match, If-None-Match, If-Range, If-Range, If-Unmodified-Since, Max-Forwards, Proxy-Authorization, Range, Referer, User-Agent. Extensions to the request header field require support from both parties in the communication. If there are unsupported request header fields, they will generally be processed as entity header fields.

(8) Accept

Tell the web server what media type it accepts. */* means any type, and type/* means all subtypes of this type, type/sub-type.

(9) Accept-Charset

The browser tells the server the character sets it can accept.

(10) Accept-Encoding

The browser declares the encoding method it receives, usually specifying the compression method, whether compression is supported, and what compression method is supported (gzip, deflate).

(11) Accept-Language

The browser declares the language it receives. The difference between language and character set: Chinese is a language, and Chinese has multiple character sets, such as big5, gb2312, gbk, etc.

(12) Authorization

When the client receives a WWW-Authenticate response from a WEB server, it uses this header to respond to the WEB server with its own authentication information.

(13) If-Match

If the object's ETag has not changed, it actually means that the object has not changed, and then the requested action is executed to obtain the document.

(14) If-None-Match

If the ETag of the object changes, it actually means that the object has also changed, and then the requested action is executed to obtain the document.

(15) If-Modified-Since

If the requested object has been modified since the time specified in the header, the requested action is performed (such as returning the object). Otherwise, the code 304 is returned to tell the browser that the object has not been modified. For example: If-Modified-Since: Thu, 10 Apr 2008 09:14:42 GMT

(16) If-Unmodified-Since

The requested action (such as returning the object) is performed only if the requested object has not been modified after the time specified in the header.

(17) If-Range

The browser tells the web server, if the object I request has not changed, give me the missing part, if the object has changed, give me the whole object. The browser sends the ETag of the requested object or the last modification time it knows to the web server, so that it can determine whether the object has changed. It is always used with the Range header.

(18) Range

The browser (such as Flashget multi-threaded download) tells the web server which part of the object it wants to get. For example: Range: bytes=1173546

(19) Proxy-Authenticate

The proxy server responds to the browser, asking it to provide proxy authentication information.

(20) Proxy-Authorization

The browser responds to the proxy server's authentication request, providing its own identity information.

(21) Host

The client specifies the domain name/IP address and port number of the web server that it wants to access. For example, Host: rss.sina.com.cn

(22) Referer

The browser tells the WEB server which web page URL it got the URL/URL in the current request from, for example: Referer: http://www.ecdoer.com/

(23) User-Agent

The browser identifies itself (what kind of browser it is). For example: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

3. HTTP Response Header

The response header provides some additional information to the client, such as who is sending the response, the function of the responder, and even some special instructions related to the response. These headers help the client process the response and initiate better requests in the future. The response header fields include Age, Location, Proxy-Authenticate, Public, Retry- After, Server, Vary, Warning, and WWW-Authenticate. The extension of the response header field requires support from both parties of the communication. If there is an unsupported response header field, it will generally be processed as an entity header field.

(24) Age

When a proxy server responds to a request with an entity from its own cache, it uses this header to indicate how long it has been since the entity was created.

(25) Server

The WEB server indicates its software and version. For example: Server: Apache/2.0.61 (Unix)

(26) Accept-Ranges

The web server indicates whether it accepts requests to obtain part of an entity (such as a part of a file). bytes: indicates acceptance, none: indicates rejection.

(27) Vary

The WEB server uses the content of this header to tell the Cache server under what conditions the object returned by this response can be used to respond to subsequent requests. If the source WEB server receives the first request message, the header of its response message is: Content-Encoding: gzip; Vary: Content-Encoding, then the Cache server will analyze the header of the subsequent request message and check whether its Accept-Encoding is consistent with the Vary header value of the previous response, that is, whether the same content encoding method is used. This can prevent the Cache server from responding to browsers that do not have the decompression capability with the compressed entity in its own cache. For example: Vary: Accept-Encoding.

4. HTTP Entity Header

The entity header provides a lot of information about the entity and its contents, from information about the object type to the various valid request methods that can be used on the resource. In short, the entity header can tell the recipient what it is processing. Both request messages and response messages can contain entity information, which generally consists of entity header fields and entities. The entity header field contains the original information about the entity. The entity header includes the informational headers Allow and Location, the content headers Content-Base, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, and the cache headers Etag, Expires, Last-Modified, and extension-header.

(28) Allow

Which request methods the server supports (such as GET, POST, etc.).

(29) Location

Indicates where the client should go to retrieve the document, and is used to locate the receiving end to the location of the resource (URL). Location is usually not set directly, but through the sendRedirect method of HttpServletResponse, which also sets the status code to 302.

(30) Content-Base

The base URL to use when resolving relative URLs in the body.

(31) Content-Encoding

The web server indicates what compression method (gzip, deflate) it uses to compress the object in the response. For example: Content-Encoding: gzip

(32) Content-Language

The web server tells the browser the best natural language to use when understanding the subject.

(33) Content-Length

The web server tells the browser the length or size of the object it responds to, for example: Content-Length: 26012

(34) Content-Location

The physical location of the resource.

(35) Content-MD5

MD5 checksum of the body.

(36) Content-Range

The entity header is used to specify the insertion position of a part of the entire entity. It also indicates the length of the entire entity. When the server returns a partial response to the client, it must describe the range covered by the response and the length of the entire entity. General format: Content-Range: bytes-unitSPfirst-byte-pos-last-byte-pos/entity-length. For example, the form of the 500-byte subfield of the transmission header is: Content-Range: bytes0-499/1234 If an http message contains this section (for example, a response to a range request or an overlapping request for a series of ranges), Content-Range indicates the range transmitted, and Content-Length indicates the actual number of bytes transmitted.

(37) Content-Type

The web server tells the browser the type of the object it responds to. For example: Content-Type: application/xml

(38) Etag

It is the mark value of an object (such as a URL). For an object, such as an HTML file, if it is modified, its Etag will also be modified. Therefore, the role of ETag is similar to that of Last-Modified, which is mainly used by the WEB server to determine whether an object has changed. For example, when requesting an HTML file last time, its ETag was obtained. When requesting this file again this time, the browser will send the previously obtained ETag value to the WEB server, and then the WEB server will compare this ETag with the current ETag of the file, and then know whether the file has changed.

(39) Expires

The web server indicates when the entity will expire. For expired objects, they can only be used to respond to client requests after their validity has been verified with the web server. This is the HTTP/1.0 header. For example: Expires: Sat, 23 May 2009 10:02:12 GMT

(40) Last-Modified

The last modification time of the object considered by the web server, such as the last modification time of the file, the last generation time of the dynamic page, etc. For example: Last-Modified: Tue, 06 May 2008 02:42:43 GMT

2. HTTP Request Header Information

1. HTTP request method

Note: "GET" and "POST" are mainly used.

Example: POST /test/tupian/cm HTTP/1.1

Divided into three parts:

• POST: HTTP request method
• /test/tupian/cm: Request the directory address (or instruction) of the Web server
• HTTP/1.1: URI (Uniform Resource Identifier) ​​and its version

Note: In Ajax, this corresponds to the method attribute setting.

2. Host

Description: The requested web server domain name address

3. User-Agent

Description: Detailed information about the browser type running on the HTTP client. Through this header information, the web server can determine the client browser type of the current HTTP request.

Example: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

4. Accept

Description: Specifies the content types that the client can receive. The order in which the content types are received by the client indicates the order in which they are received.

Example: Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Note: In the Ajax code package of Prototyp (1.5), Accept is set to "text/javascript, text/html, application/xml, text/xml, */*" by default. This is because Ajax obtains the Json data mode returned by the server by default. In the Ajax code, you can use the setRequestHeader function method in the XMLHttpRequest object to dynamically set these header information.

5. Accept-Language

Description: Specifies the preferred language used by HTTP client browsers to display returned information.

Example: Accept-Language: zh-cn,zh;q=0.5 The default here is Chinese.

6. Accept-Encoding

Description: Specifies the compression encoding type of the web server return content that the client browser can support. It means that the server is allowed to compress the output content before sending it to the client to save bandwidth. What is set here is the return compression format that the client browser can support.

Example: Accept-Encoding: gzip,deflate

Note: In fact, in many product lines of Baidu, Apache compresses the data in gzip format before returning the page data to the client.

7. Accept-Charset

Description: The character encoding sets that the browser can accept.

Example: Accept-Charset: gb2312,utf-8;q=0.7,*;q=0.7

8. Content-Type

Description: Displays the content type submitted by this HTTP request. Generally, this attribute needs to be set only when submitting a post.

Example: Content-type: application/x-www-form-urlencoded;charset:UTF-8

Note: The Content-Type attribute value can be encoded in the following two types:

• "application/x-www-form-urlencoded": The encoding type used when the form data is submitted to the server. The default value is "application/x-www-form-urlencoded". However, this encoding method is inefficient when sending large amounts of text, text containing non-ASCII characters, or binary data to the server.
• "multipart/form-data": When uploading files, the encoding type used should be "multipart/form-data", which can send both text data and binary data upload.

When submitting a single data, you can use "application/x-www-form-urlencoded"; when submitting a file, you need to use the "multipart/form-data" encoding type.

The Content-Type attribute still specifies the charset character encoding of the submitted content. Generally, it is not set, it just tells the web server what character encoding to use for the data submitted by post.

Generally, during the development process, the front-end engineer and the back-end UI engineer will discuss what character encoding format to use for post submission, and then the back-end UI engineer will parse the submitted data according to the fixed character encoding. Therefore, the charset set here has little effect.

9. Connection

Description: Indicates whether a persistent connection is required. If the web server sees the value here as "Keep-Alive" or sees that the request uses HTTP 1.1 (HTTP 1.1 uses a persistent connection by default), it can take advantage of the persistent connection and significantly reduce the time required for downloading when the page contains multiple elements (such as applets, pictures). To achieve this, the web server needs to send a Content-Length (the length of the body of the returned information) header in the HTTP header information returned to the client. The simplest way to implement this is to first write the content to a ByteArrayOutputStream, and then calculate its size before officially writing the content.

Example: Connection: keep-alive

10. Keep-Alive

Description: Displays the Keep-Alive time of this HTTP connection. It keeps the connection between the client and the server valid. When there is a subsequent request to the server, the Keep-Alive function avoids establishing or re-establishing the connection. In the past, HTTP requests were one-stop connections. After the HTTP/1.1 protocol, there are long connections, that is, the connection will not be disconnected within the specified Keep-Alive time.

Example: Keep-Alive: 300

11. Cookies

Note: When an HTTP request is sent, all cookie values ​​stored under the requested domain name will be sent to the web server.

12. Referer

Description: Contains a URL from which the user accesses the currently requested page.

3. HTTP Response Header Information

4. http return error code

HTTP response code The response code consists of three decimal digits, which appear in the first line of the response sent by the HTTP server. There are five types of response codes, represented by their first digit:

• 1xx: Information, request received, continue processing
• 2xx: Success, the behavior was successfully accepted, understood, and adopted
• 3xx: Redirection, further actions must be performed to complete the request
• 4xx: Client error, the request contains a syntax error or the request cannot be implemented
• 5xx: Server error. The server cannot implement an obviously invalid request.

The following table shows each response code and its meaning: