Request header

Accept

MIME type accepted by the browser. For example: Accept: text/ HTML means that the browser can Accept text/ HTML as the type of document that the server sends back. If the server cannot return text/ HTML data, the server should return a 406 error (Non acceptable). The wildcard * indicates any type. For example, Accept: / indicates that the browser can handle all types.

Accept-Encoding

Browsers declare the encoding methods they accept, usually specifying compression methods, whether they support compression, and what compression methods they support (gzip, deflate); Servlets can return GZIP-encoded HTML pages to gZIP-enabled browsers. In many cases this can reduce download times by 5 to 10 times. For example, accept-encoding: gzip, deflate. If this field is not set in the request message, the server assumes that the client is okay with various content encodings.

Accept-Language

The browser declares the language it receives. Big5, GB2312, GBK, etc. For example, accept-language: en-us. Accept-Language: zh-CN,zh; Q = 0.9. If this header field is not set in the request message, the server assumes that the client is acceptable to all languages.

Accept-Charset

Character set acceptable to the browser. If this field is not set in the request message, any character set is accepted by default.

Content-Type

Request MIME information corresponding to the entity, for example: Content-Type: application/ X-www-form-urlencoded.

Referer

Contains a URL from which the user accesses the currently requested page. The server that provides the context of the Request tells the server from which I linked, for example from my home page to a friend’s site, and the server can count from the HTTP Referer how many users click on my home page to visit his site every day. For example: Referer: translate.google.cn/?hl=zh-cn&t…

Connection

For example, Connection: keep-alive After a web page is opened, the TCP Connection used to transmit HTTP data between the client and the server is not closed. If the client accesses the web page on the server again, the existing Connection continues. HTTP 1.1 makes persistent connections by default. Take advantage of persistent connections to significantly reduce the time required for downloading when a page contains multiple elements (such as applets, images). To do this, the Servlet needs to send a Content-Length header in the reply. The easiest way to do this is to write the Content to a ByteArrayOutputStream and then calculate its size before writing it out.

Connection: Close Indicates that after a Request is completed, the TCP Connection used to transmit HTTP data between the client and the server is closed. When the client sends a Request again, the TCP Connection needs to be re-established.

Proxy-Connection

As with Connection, the proxy becomes the request header.

Host

(This header field is required when sending a request) is used to specify the Internet host and port number of the requested resource, usually extracted from an HTTP URL. HTTP/1.1 requests must contain a host header field, or the system will return a 400 status code. Such as: We input in the browser: www.guet.edu.cn/index.html, the browser sends a request message, will contain the Host request header fields: Host:www.guet.edu.cn, here to use the default port number 80, if the specified port number, becomes: Host: Specify the port number.

Cookie

One of the most important request headers sends the value of the cookie to the HTTP server.

Content-Length

Represents the length of the request message body. For example, content-Length: 38.

Authorization

Authorization information, usually in response to wwW-Authenticate headers sent by the server. It is used to prove that a client has the right to view a resource. When a browser visits a page and receives a response code 401 (unauthorized) from the server, it can send a request containing the Authorization request header field and ask the server to validate it.

Ua-pixels, UA-color, UA-OS, UA-CPU

A non-standard request header sent by some versions of Internet Explorer indicating screen size, color depth, operating system, and CPU type.

From

The email address of the request sender, which is used by special Web clients and is not used by browsers.

Range

One or more subscopes of an entity can be requested. For example, the first 500 bytes: bytes=0-499 The second 500 bytes: bytes=500-999 The last 500 bytes: bytes=-500 The range after 500 bytes: bytes=500- the first and last bytes: Bytes =0-0,-1 specifies several ranges at the same time: bytes=500-600,601-999 But the server can ignore this request header. If the unconditional GET contains the Range request header, the response is returned with status code 206 (PartialContent) instead of 200 (OK).

User-Agent:

Tell the server what operating system, browser version, and name the client is using. Such as: Mozilla / 5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1

The if-modified-since:

Send the last modified time of the browser-cached page to the server, and the server compares this time with the last modified time of the actual file on the server. If the time is consistent, 304 is returned and the client uses the local cache file directly. If the time is inconsistent, 200 and the new file contents are returned. Once received, the client will discard the old file, cache the new file, and display it in the browser. For example, if-modified-since: Thu, 09 Feb 2012 09:07:57 GMT

If None – Match:

If-none-match works with ETag by adding ETag information to the HTTP Response. When the user requests the resource again, if-none-match information (the value of ETag) is added to the HTTP Request. If the server verifies that the resource’s ETag has not changed (the resource has not been updated), a 304 status is returned telling the client to use the local cache file. Otherwise it will return 200 status and new resources and Etag. Using such a mechanism will improve the performance of the site. For example, if-none-match: “03f2b33c0BFCC1:0”.

Pragma:

Specifying a “no-cache” value means that the server must return a refreshed document, even if it is a proxy server and already has a local copy of the page; In HTTP/1.1, it works exactly like cache-control :no-cache. There is only one use of Pargma, e.g. Pragma: no-cache note: in HTTP/1.0, only Pragema:no-cache is implemented, not cache-control

Cache-control:

Specify the caching mechanism that requests and responses follow. Cache instructions are one-way (Cache instructions present in the response may not be present in the request) and independent (setting cache-control in either the request message or the response message does not modify the Cache processing in the other message processing).

The cache instructions at 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, max-age, and S-maxage.

  • Cache-control :Public can be cached by any Cache
  • Cache-control :Private content is only cached in the Private Cache
  • Cache-control :no-cache All contents are not cached
  • Cache-control :no-store Prevents important information from being inadvertently published. Sending in the request message will result in neither the request nor the response message using caching.
  • Cache-control :max-age indicates that the client can receive a response with a lifetime not longer than the specified time in seconds.
  • Cache-control: Min-fresh indicates that the client can receive a response with a response time less than the current time plus the specified time.
  • Cache-control :max-stale indicates that the client can receive response messages beyond the timeout period. If you specify a value for a max-stale message, the client can receive a response message beyond the specified value for the timeout period.