HTTP header details

Hypertexttransferprotocol is short for Hypertext Transfer Protocol. It is used to transmit WWW Data. For details about HTTP, see rfc2616. The HTTP protocol uses the request/response model. The client sends a request to the server. The request header contains the request method, Uri, Protocol version, and message structure similar to mime containing the request modifier, customer information, and content. The server responds with a status line. The corresponding content includes the version of the Message Protocol, and the server information, entity metadata, and possible entity content are added to the success or error code.

Generally, HTTP messages include the request message sent from the client to the server and the response message sent from the server to the client. These two types of messages are composed of a starting line, one or more header fields, an empty line that is only the end of the header field, and an optional message body. The HTTP header includes four parts: Common headers, request headers, response headers, and object headers. Each header field consists of a domain name, a colon (:), and a domain value. The domain name is case-insensitive. You can add any number of space characters before the Domain value. The header field can be expanded to multiple rows. At least one space or Tab character is used at the beginning of each line.

Common header fields

The general header domain includes the header domains supported by both request and response messages. The general header domain includes cache-control, connection, date, Pragma, transfer-encoding, upgrade, and. The extension of the common header domain requires both parties to support this extension. If a common header domain is not supported, it is generally processed as the object header domain. The following describes some general header fields used in UPnP messages.

Cache-control header field

Cache-control specifies the cache mechanism that requests and responses follow. Setting cache-control in a request message or response message does not modify the cache processing process of another message. The cache commands in the request include no-cache, no-store, Max-age, Max-stale, Min-fresh, only-if-cached, commands in the Response Message include public, private, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, and Max-age. The instructions in each message are as follows:

Public indicates that the response can be cached in any cache area.

Private indicates that the whole or part of the response message of a single user cannot be processed by the shared cache. This allows the server to only describe part of the user's response message, which is invalid for requests of other users.

No-Cache indicates that the request or response message cannot be cached.

No-store is used to prevent the unintentional release of important information. Sending a request message does not cache the request and response messages.

Max-age indicates that the client can receive responses with a lifetime not greater than the specified time (in seconds.

Min-fresh indicates that the client can receive a response whose response time is earlier than the current time plus the specified time.

Max-stale indicates that the client can receive response messages beyond the timeout period. If the value of the Max-stale message is specified, the client can receive response messages that exceed the timeout period.

Date header field

The date header field indicates the message sending time. The description format of the time is defined by rfc822. For example, Date: Mon, 31dec200104: 25: 57gmt. The time described in date indicates the world standard time. You need to know the time zone of the user to convert the local time.

Pragma header domain

The Pragma header field is used to contain specific instructions. The most common method is Pragma: No-cache. The meaning of HTTP/1.1 is the same as that of cache-control: No-cache.

Request Message

The format of the first action of the request message is as follows:

Methodsprequest-urisphttp-versioncrlfmethod indicates the method for completing request-Uri. This field is case sensitive, including options, get, Head, post, put, delete, and trace. Methods get and head should be supported by all common Web servers, and implementation of all other methods is optional. The get method retrieves the information identified by request-Uri. The head method also retrieves the information identified by request-Uri, but does not return the message body during the response. The post method can request the server to receive entity information contained in the request. It can be used to submit forms and send messages to newsgroups, BBS, contact groups, and databases.

SP indicates space. Request-Uri follows the URI format. When this field is asterisk (*), the request is not used for a specific resource address, but for the server itself. HTTP-version indicates the supported HTTP Version. For example, HTTP/1.1. CRLF indicates a line feed. The request header field allows the client to transmit request or additional information about the client to the server. The request header field may contain the following fields: Accept, accept-charset, accept-encoding, accept-language, authorization, from, host, if-modified-since, if-match, and if-none. -match, if-range, if-range, if-unmodified-since, Max-forwards, proxy-authorization, range, Referer, and User-Agent. Both parties need to support the expansion of the Request Header domain. If an unsupported Request Header domain exists, it is generally processed as an object header domain.

Typical request message:

Get http://download.microtool.de: 80/somedata.exe
HOST: download.microtool.de
Accept :*/*
Pragma: No-Cache
Cache-control: No-Cache
Referer: http://download.microtool.de/
User-Agent: Mozilla/4.04 [En] (Win95; I; NAV)
Value Range: bytes = 554554-

In the preceding example, the first line indicates the HTTP client (which may be a browser or download ).Program) Get the file under the specified URL through the get method. The brown part indicates the information of the request header field, and the green part indicates the general header part.

Host Header domain

The Host Header specifies the intenet host and port number of the requested resource, which must represent the location of the original server or gateway of the request URL. The HTTP/1.1 request must contain the Host Header domain; otherwise, the system returns the status code 400.

Referer header field

The referer header field allows the client to specify the source resource address of the request URI, which allows the server to generate a rollback linked list for login and Cache Optimization. He also allows abolished or erroneous connections to be tracked for maintenance purposes. If the requested URI does not have its own URI address, the Referer cannot be sent. If some Uri addresses are specified, this address is a relative address.

Range Header

The range header field can request one or more sub-ranges of an object. For example,

Indicates the first 500 Bytes: bytes = 0-499

Indicates the second 500 Bytes: bytes = 500-999

Indicates the last 500 Bytes: bytes =-500

Indicates the range after 500 Bytes: bytes = 500-

First and last Bytes: bytes = 0-0,-1

Specify the following ranges: bytes = 500-600,601-999.

However, the server can ignore this request header. If the unconditional get contains the range request header, the response will be returned with the status code 206 (partialcontent) instead of 200 (OK ).

User-Agent header domain

The content of the User-Agent header contains the user information that sends the request.

Response Message

The format of the first response message is as follows:

HTTP-versionspstatus-codespreason-phrasecrlf

HTTP-version indicates the supported HTTP Version. For example, HTTP/1.1. Status-code is a result of three numbers.Code. Reason-phrase provides a simple text description for status-code. Status-code is mainly used for automatic machine identification, and reason-phrase is mainly used to help users understand. The first digit of status-code defines the category of the response. The last two digits do not have a category. The first number may have 5 different values:

1xx: Information Response class, indicating that the request is received and processed continuously

2XX: Successful response class, indicating that the action is successfully received, understood, and accepted

3xx: redirect response class. To complete the specified action, you must accept further processing.

4xx: client error. The client request contains a syntax error or cannot be correctly executed.

5xx: server error. The server cannot correctly execute a correct request.

The response header field allows the server to transmit additional information that cannot be placed in the status line. These fields mainly describe the server information and further request-Uri information. The Response Header includes age, location, proxy-authenticate, public, retry-after, server, vary, warning, and WWW-authenticate. The expansion of the Response Header domain requires both parties to support the communication. If an unsupported Response Header domain exists, it is generally processed as an entity header domain.

Typical response message:

HTTP/1.0200ok

Date: Mon, 31dec200104: 25: 57gmt

Server: Apache/1.3.14 (UNIX)

Content-Type: text/html

Last-modified: Tue, 17apr200106: 46: 28gmt

Etag: "a030f020ac7c01: 1e9f"

Content-Length: 39725426

Content-range: bytes554554-40279979/40279980

The first line in the preceding example indicates that the HTTP server responds to a get method. The brown part indicates the information of the response header field, the green part indicates the general header part, and the red part indicates the information of the object header field.

Location Response Header

The location response header is used to redirect the receiver to a new URI address.

Server Response Header

The server response header contains the software information of the original server that processes the request. This domain can contain multiple product identifiers and comments. Product identifiers are generally sorted by importance.

Entity

Request messages and response messages can both contain entity information. entity information is generally composed of entity header fields and entities. The object header contains the original information about the object, object headers include allow, content-base, content-encoding, content-language, Content-Length, content-location, Content-MD5, content-range, content-type, etag, expires, last -modified and extension-header. Extension-header allows the client to define new object headers, but these fields may not be recognized by the recipient. An object can be an encoded byte stream. Its encoding method is defined by content-encoding or Content-Type. Its length is defined by Content-Length or content-range.

Content-Type object header

The Content-Type object header is used to indicate the media type of the object to the receiver, specify the object media type sent by the Head Method to the receiver, or request media type content-range object header sent by the get method.

The content-range object header is used to specify the insertion position of a part of the entire object. It also indicates the length of the entire object. When the server returns a partial response to the customer, it must describe the response coverage and the length of the entire object. General format:

Content-range: bytes-unitspfirst-byte-pos-last-byte-pos/entity-Lety

For example, if an HTTP message contains content-range: bytes0-500 (for example, content-range indicates the transfer range, and Content-Length indicates the number of bytes actually transmitted.

Last-modified Object Header

The last-modified object header specifies the last revision time of the content saved on the server.

Response Header	Description
Allow	Which request methods (such as get and post) are supported by the server ).
Content-Encoding	The document encoding (encode) method. The content type specified by the Content-Type header can be obtained only after decoding. Gzip compression can significantly reduce the download time of HTML documents. Java gzipoutputstream can be easily compressed by gzip, but it is supported only by Netscape on UNIX and IE 4 and IE 5 on Windows. Therefore, Servlet should view the accept-encoding header (request. getheader ("Accept-encoding") checks whether the browser supports gzip, returns the gzip-compressed HTML page for a browser that supports gzip, and returns a common page for other browsers.
Content-Length	Content Length. This data is required only when the browser uses a persistent HTTP connection. If you want to take advantage of persistent connections, you can write the output document to bytearrayoutputstram, view its size, put the value in the Content-Length header, and finally use bytearraystream. writeto (response. content sent by getoutputstream.
Content-Type	The MIME type of the subsequent documents. Servlet is text/plain by default, but it must be explicitly specified as text/html. Because Content-Type is often set, httpservletresponse provides a dedicated method setcontenttyep.
Date	The current GMT time. You can use setdateheader to set this header to avoid the trouble of converting the time format.
Expires	When should I think the document has expired and no longer cache it?
Last-modified	The last modification time of the document. You can use the IF-modified-since request header to provide a date. This request is considered as a condition get. Only documents whose modification time is later than the specified time will be returned, otherwise, a 304 (not modified) status is returned. Last-modified can also be set using the setdateheader method.
Location	Indicates where the customer should extract documents. Location is usually not set directly, but through the sendredirect method of httpservletresponse. This method also sets the status code to 302.
Refresh	Indicates the time after which the browser should refresh the document, in seconds. In addition to refreshing the current document, you can also use setheader ("refresh", "5; url = http: // host/path") to allow the browser to read the specified page. Note that this feature is typically implemented by setting <meta HTTP-EQUIV = "refresh" content = "5; url = http: // host/path"> In the head area of the HTML page, because, automatic refresh or redirection is important for HTML writers who cannot use CGI or servlet. However, for servlet, it is more convenient to directly set the refresh header. Note that refresh indicates "refresh the page after n seconds or access the specified page", rather than "refresh the page or access the specified page every n seconds ". Therefore, continuous refreshing requires that a refresh header be sent each time, and sending the 204 status code can prevent the browser from refreshing, whether it's using the refresh header or <meta HTTP-EQUIV = "refresh"...>. Note that the refresh header is not part of the official HTTP 1.1 Specification but an extension, but is supported by both Netscape and IE.
Server	The name of the server. Servlet generally does not set this value, but is set by the Web server.
Set-Cookie	Set the cookie associated with the page. Servlet should not use response. setheader ("Set-cookie",...), but should use the dedicated method addcookie provided by httpservletresponse. For more information about Cookie settings, see the following section.
WWW-Authenticate	What type of authorization information should the customer provide in the Authorization header? This header is required in the Response containing the 401 (unauthorized) status row. For example, response. setheader ("www-authenticate", "Basic realm = \" executives \""). Note that servlet generally does not handle this problem, but allows the Web server to control access to password-protected pages (for example,. htaccess ).