The header information of HTTP protocol is detailed

HTTP (hypertexttransferprotocol) is the abbreviation of Hypertext Transfer Protocol, it is used to transmit data of WWW mode, please refer to RFC2616 for details of HTTP protocol. The HTTP protocol uses a request/response model. The client sends a request to the server that contains the requested method, URI, protocol version, and a mime-like message structure that contains the request modifiers, customer information, and content. The server responds with a status line, which includes the version of the message protocol, the success or error code plus the containing server information, entity meta information, and possible entity content.

Typically, HTTP messages include the client's request message to the server and the server's response message to the client. The two types of messages consist of a starting row, one or more header fields, and an empty row and an optional message body that is just the end of the head field. The HTTP header domain includes a universal header, a request header, a response header, and an entity header four parts. Each header field consists of a domain name, a colon (:), and a field value of three parts. Domain names are case-insensitive, field values can be added to any number of spaces, and header fields can be extended to multiple lines, at the beginning of each line, with at least one space or tab.

Universal Header Field

The Common header field contains the header fields supported by both the request and response messages, and the Common header field contains Cache-control, Connection, Date, Pragma, transfer-encoding, Upgrade, Via. Extensions to the common header domain require both sides of the communication to support this extension, and if there are unsupported common header domains, they will normally be treated as entity headers. The following is a brief introduction to a few common header domains used in UPnP messages.

Cache-control header Field

CACHE-CONTROL Specifies the caching mechanism that the request and response follow. Setting Cache-control in a request message or in a response message does not modify the caching process during another message handling process. The cache directives requested 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 instructions in each message have the following meanings:

Public indicates that the response can be cached by any buffer.

Private indicates that the entire or partial response message for a single user cannot be handled by the shared cache. This allows the server to simply describe a partial response message from the user, which is not valid for other users ' requests.

No-cache indicates that a request or response message cannot be cached

No-store is used to prevent important information from being inadvertently released. Sending in a request message will not use caching for both request and response messages.

Max-age indicates that the client can receive a response that is not longer than the specified time in seconds.

Min-fresh indicates that the client can receive response times that are less than the current time plus a specified time.

Max-stale indicates that the client can receive response messages that exceed the timeout period. If you specify a value for the Max-stale message, the client can receive a response message that exceeds the specified value for the timeout period.

Date Header Field

The Date header field represents the time when the message was sent, and the description format of the time is defined by rfc822. For example, Date:mon,31dec200104:25:57gmt. When the time represented by the date represents the world standard, it is converted to local time and needs to know the time zone in which the user is located.

pragma header field

The Pragma header field is used to contain implementation-specific instructions, most commonly pragma:no-cache. In the http/1.1 protocol, it has the same meaning as Cache-control:no-cache.

Request message

The first behavior of the request message is in the following format:

Methodsprequest-urisphttp-versioncrlfmethod indicates that the field is case sensitive for Request-uri completion, including options,, POST, put, DELETE , TRACE. The method get and head should be supported by all common Web servers, and the implementation of all other methods is optional. The GET method retrieves the information identified by the Request-uri. The head method is also to retrieve the information identified by the Request-uri, except that the message body is not returned when responding. The Post method can request the server to receive entity information contained in the request, which can be used to submit the form and send messages to newsgroups, BBS, mail groups, and databases.

The SP represents a space. Request-uri follows the URI format, which, when Cheweishing (*), describes the request not for a particular resource address, but for the server itself. Http-version represents a supported version of HTTP, for example, http/1.1. CRLF represents a line feed return character. The request header domain allows the client to deliver additional information about the request or 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, 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 support, and if an unsupported request header field exists, it will normally be treated as an entity header domain.

A 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)

range:bytes=554554-

The first line of the previous example indicates that the HTTP client (possibly the browser, the download program) obtains the file under the specified URL through the Get method. The brown section represents the information for the Request header field, and the green section represents the generic head section.

Host Header Field

The Host header field specifies the Intenet host and port number of the requesting resource, and must represent the location of the original server or gateway that requested the URL. The http/1.1 request must contain a host header domain or the system will return with a 400 status code.