HTTP request header and response header

The Http protocol defines many methods of interacting with the server, the most basic of which are 4 types, namely GET, POST, PUT, and DELETE. A URL address is used to describe a resource on the network, and the GET, POST, PUT, and DELETE in HTTP correspond to the four operations of checking, modifying, adding, and deleting this resource. The most common ones we use are GET and POST. . GET is generally used to obtain/query resource information, and POST is generally used to update resource information.

1. Interpretation of HTTP header information

The HTTP header field includes four parts: general header, request header, response header and entity header. Each header field is composed of a domain name, a colon (:) and a field value.

General header: It is a header that can be used by both the client and the server. It can provide some very useful general functions between the client, server and other applications, such as the Date header.

Request header: It is unique to the request message. They provide some additional information for the server, 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 customer service is interacting with, such as the Server header.

Entity header: refers to the header used to deal with the body part of the entity. For example, the entity header can be used to describe the data type of the entity body, such as the Content-Type header.

HTTP general header

The general header field includes header fields that are supported by both request and response messages. The general header field includes cache headers Cache-Control, Pragma, and information headers Connection, Date, Transfer-Encoding, Update, and Via.


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

no-cache: Indicates that the request or response message cannot be cached. In fact, it can be stored in the local cache, but the cache cannot provide it to the client before the freshness verification with the original server.

no-store: The cache should delete all traces of the document from the storage as soon as possible, because it may contain sensitive information.

max-age: The cache cannot return documents whose cache time is longer than the specified seconds of max-age. If the specified seconds are not exceeded, the browser will not send the corresponding request to the server, and the data will be returned directly from the cache; after this time period, the server will be further sent Decide whether to return new data or still be provided by the cache. If the max-stale command is also sent at the same time, the usage period may exceed its expiration time.

min-fresh: The document should be kept fresh for at least the specified second in the future, and the cached object whose freshness lifetime is greater than the sum of its current Age and min-fresh values ​​is accepted.

max-stale: indicates that the client can receive expired response messages. If the value of the max-stale message is specified, the client can receive response messages that are expired but within the specified value.

only-if-cached: Only when a copy exists in the cache, the client will get a copy.

Public: Indicates that the response can be cached by any cache area, and the cached content can be used to respond to any user.

Private: Indicates that the entire or part of the response message of a single user cannot be processed by the shared cache, and the cached content 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 is Pragma:no-cache. In the HTTP/1.1 protocol, its meaning is the same as Cache-Control:no-cache.


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 is a persistent connection by default), it can take advantage of the persistent connection when the page contains multiple elements (such as Applet, picture), which significantly reduces the time required for downloading. To achieve this, the Servlet needs to send a Content-Length header in the response. The easiest way to achieve this is to write the content into the ByteArrayOutputStream first, and then calculate its size before the content is officially written.

Close: Tell the WEB server or proxy server to disconnect after completing the response to this request and do not wait for subsequent requests for this connection.

Keepalive: Tell the WEB server or proxy server to keep the connection after completing the response to this request and wait for subsequent requests for this connection.

Keep-Alive: If the browser requests to keep the connection, the header indicates how long (in seconds) the WEB server is expected to keep the connection, such as Keep-Alive: 300.


The Date header field indicates the time when the message was sent. The server response must include this header because the cache is used when evaluating the freshness of the response. The description format of the time is defined by RFC822. For example, Date:Mon, 31 Dec 2001 04:25:57 GMT. When the time described by Date represents the world standard, when converting to local time, you need to know the time zone of the user.


The WEB server indicates how it encodes the response message body (not the object in the message body), such as whether it is chunked, for example: Transfer-Encoding: chunked


It can specify another protocol that may be completely different. For example, an HTTP/1.1 client can send an HTTP/1.0 request to the server, which contains an Update header with a value of "HTTP/1.1", so that the client can test the server Do you also use HTTP/1.1?


List the proxy servers that the response from the client to the OCS or the opposite direction has passed, and what protocol (and version) they used to send the request.

When a client request arrives at the first proxy server, the server will add the Via header to the request sent by itself, 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 the request sent by yourself, and add your own related information to the back, and so on. When the OCS receives the last proxy server's request, it checks the Via header. Know the route the request has taken. For example: Via: 1.0 (squid/2.6.STABLE13)

HTTP request header

The request header is used to indicate who or what is sending the request, where the request originated, 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. The extension of the request header field requires both communication parties to support it. If there is an unsupported request header field, it will generally be treated as an entity header field.


Tell the WEB server what media type it accepts, / means any type, type/* means all sub-types under this type, type/sub-type.


The browser tells the server which character set it can receive.


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


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 and so on.


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


If the ETag of the object has not changed, it actually means that the object has not changed before performing the requested action and obtaining the document.


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


If the requested object is modified after the time specified by the header, the requested action (such as returning the object) is executed, 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


If the requested object has not been modified after the time specified by the header, the requested action (such as returning the object) is performed.


The browser tells the WEB server that if the object I requested has not changed, it will give me the missing part, and if the object has changed, it will give me the entire object. The browser sends the ETag of the requested object or the last modification time it knows to the WEB server to let it judge whether the object has changed. Always use with Range head.


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


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


The browser responds to the authentication request of the proxy server and provides its own identity information.


The client specifies the domain name/IP address and port number of the WEB server that it wants to access. Such as Host:


The browser indicates to the WEB server from which web page URL it obtained the URL/URL in the current request, for example: Referer:


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

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 make better requests in the future. The response header domain includes Age, Location, Proxy-Authenticate, Public, Retry-After, Server, Vary, Warning, WWW-Authenticate. The extension of the response header field requires both communication parties to support it. If there is an unsupported response header field, it will generally be treated as an entity header field.


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


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


The WEB server indicates whether it accepts a request to obtain a part of its entity (such as a part of a file). bytes: means accept, none: means not accept.


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

HTTP entity header

The entity header provides a large amount of information about the entity and its content, from information about the object type to various effective request methods that can be used for resources. In short, the entity header can tell the receiver what it is dealing with. Both the request message and the response message 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 information header Allow and Location, and the content header Content-Base, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content- Range, Content-Type, cache header Etag, Expires, Last-Modified, extension-header.


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


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


The base URL used when parsing the relative URL in the body.


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


The WEB server tells the browser the most suitable natural language to use when understanding the subject.


The WEB server tells the browser the length or size of the responding object, for example: Content-Length: 26012


The actual location of the resource.


The MD5 checksum of the main body.


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


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


It is the tag value of an object (such as URL). As far as an object is concerned, such as an html file, if it is modified, its Etag will not be modified. Therefore, the role of ETag is similar to that of Last-Modified, mainly for WEB The server determines whether an object has changed. For example, when requesting an html file last time, the ETag is obtained. When the file is requested again this time, the browser will send the previously obtained ETag value to the WEB server, and then the WEB server will associate this ETag with the current file ETag compares, and then you know if the file has changed.


The WEB server indicates when the entity will expire. The expired object can only be used to respond to customer requests after verifying its validity with the WEB server. It is the header of HTTP/1.0. For example: Expires: Sat, 23 May 2009 10:02:12 GMT


The WEB server considers the last modification time of the object, such as the last modification time of the file, the last generation time of the dynamic page, and so on. For example: Last-Modified: Tue, 06 May 2008 02:42:43 GMT

2. Header information of HTTP Request

1. HTTP request method
Insert picture description here

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

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

Divided into three parts:

(1)POST: HTTP request method

(2)/test/tupian/cm: request the directory address of the Web server (or instruction)

(3) HTTP/1.1: URI (Uniform Resource Identifier) ​​and its version

Note: In Ajax, the corresponding method attribute setting.


Description: The requested web server domain name address


Description: Detailed information of the browser type that the HTTP client is running. 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: Gecko/20071127 Firefox/


Description: Specify the type of content that the client can receive. The order in the content type indicates the order in which the client receives.


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


Description: Specify the preferred language for the HTTP client browser to display the returned information.

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


Description: Specify the type of content compression encoding returned by the web server that the client browser can support. Indicates that the server is allowed to compress the output before sending it to the client to save bandwidth. And what is set here is the return compression format that the client browser can support.

实例:Accept-Encoding: gzip,deflate

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


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

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


Description: Display the content type submitted by this HTTP request. Generally, this property needs to be set only when the post is submitted.

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

Note: The value of the Content-Type attribute can be of the following two encoding types:

(1) "application/x-www-form-urlencoded": The encoding type used when the form data is submitted to the server. The default default value is "application/x-www-form-urlencoded". However, this encoding method is very inefficient when sending large amounts of text, text containing non-ASCII characters, or binary data to the server.

(2) "multipart/form-data": When uploading files, the encoding type used should be "multipart/form-data", which can send text data as well as binary data upload.

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

In the Content-Type attribute, the charset character encoding of the submitted content is still specified. Generally, it is not set, it just tells the web server which character encoding the post submitted data uses.

Generally, in the development process, the front-end engineering and the back-end UI engineer discuss what character encoding format to use for the post submission, and then the back-end UI engineer parses the submitted data according to the fixed character encoding. So the charset set here does not have much effect.


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 is a persistent connection by default), it can take advantage of the persistent connection when the page contains multiple elements (E.g. Applet, picture), which significantly reduces the time required for downloading. To achieve this, the web server needs to send a Content-Length (the length of the returned message body) header in the HTTP header information returned to the client. The simplest way to achieve this is: first write the content to the ByteArrayOutputStream, and then formally write it out Calculate its size before the content.

Example: Connection: keep-alive


Description: Display the Keep-Alive time of this HTTP connection. Make the connection between the client and the server continue to be effective. 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 a one-stop connection. After the HTTP/1.1 protocol, there is a long connection, that is, the connection will not be disconnected within the specified Keep-Alive time.

Example: Keep-Alive: 300


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


Description: Contains a URL, the user visits the currently requested page from the page represented by the URL

Guess you like