Full explanation of HTTP protocol

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:

Gethttp: // download.microtool.de/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 that the HTTP client (which may be a browser or a download program) obtains 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 the result code of three numbers. 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, transfer the form of the header 500 byte field: Content-range: bytes0-499/1234 if an HTTP message contains this section (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.