HTTP content format (Protocol)

An HTTP message consists of a client-to-server request and a server-to-client response. The request message and Response Message are both from the start line (for the request message, the start line is the request line, and for the response message, the start line is the status line), the message header, empty line (only CRLF line), message body (optional.

HTTP message headers include common headers, request headers, response headers, and object headers. Each header field consists of the name + ":" + space + value. The name of the message header field is case-insensitive.

1. Request Message format

HTTP request content consists of three parts: request line, message header (header), and optional request body (information body)

1.1 request line format:

The request line must be placed at the beginning of all content and end with a line feed. The format is as follows:

Method <space> request-Uri <space> HTTP/version <line feed return character>

1.2 method:

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.

1.3 request-Uri:

Follow the URI format. When this field is asterisk (*), the request is not used for a specific resource address, but for the server itself.

1.4 HTTP/version

Indicates the supported HTTP Version. For example, HTTP/1.1. CRLF indicates a line feed.

2. Response Message format

The HTTP Response content is composed of three parts: Response (Status) line, message header, and response body. The response line must be placed at the beginning of all content and must end with a line feed carriage return.

2.1 response line format:

HTTP/version <space> Status-Code <space> reason-phrase <line feed return character>

2.2 HTTP/version

Indicates the supported HTTP Version. For example, HTTP/1.1.

2.3 status-code

Is a result code (Status Code) consisting of three digits ). 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: A server error occurs. The server cannot correctly execute a normal request.

 

Common status codes, status descriptions, and descriptions:

200 OK // client request successful

400 bad request // The client request has a syntax error and cannot be understood by the server

401 unauthorized // The request is unauthorized. This status code must be used with the WWW-Authenticate header domain.

403 Forbidden // The server receives the request but rejects the service.

404 Not found // The requested resource does not exist. For example, the incorrect URL is entered.

500 internal server error // unexpected Server Error

503 server unavailable // The server cannot process client requests at present, and may return to normal after a period of time

2.4 reason-phrase

Status description, mainly used to help users understand.

3. 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.

3.1 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. Cache commands (values) during 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, and 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 entire 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: Used to prevent 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.

3.2 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. If you want to convert the local time, you need to know the time zone of the user.

3.3 Pragma Header field

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.

3.4 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 ).

4. Request Header domain:

Allow the client to send a request or an additional 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. To expand the request header domain, both parties must support it. If an unsupported Request Header domain exists, it is generally processed as an entity header domain.

4.1 HostHeader field

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.

4.2 RefererHeader 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. It 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.

4.3 User-Agent Header field

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

5 Request Message Header example:

Get http://www.ebdoor.com: 80/HTTP/1.0

HOST: www.ebdoor.com

Accept :*/*

Pragma: No-Cache

Cache-control: No-Cache

Referer: http://www.ebdoor.com/

User-Agent: Mozilla/4.0 (...)

Value Range: bytes = 554554-

 

Message body ....

 

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 green part indicates the request header information, and the blue part indicates the general header.

6. Response Header domain

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.

6.1 location Response Header domain

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

6.2 Server Response Header domain

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.

7. entity content

All content after the empty line ends in the header domain. The request message and response message can both contain entity information. The entity can be an encoded byte stream, its encoding method is determined by content-encoding or Content-Type in the object header field. Its length is defined by Content-Length or content-range.

8. entity header domain

The object header field describes the object information, 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, which allows the client to define new object headers, but these fields may not be recognized by the receiver.

8.1 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.

8.2 content-Range

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-Unit <space> first-byte-pos-last-byte-pos/entity-Lety

For example, if an HTTP message contains content-range: bytes0-500 (for example, for a response to a range request or a series of overlapping requests), content-range indicates the transfer range,

8.3 Content-Length

The number of bytes actually transferred. 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.

8.4 allow

Which request methods (such as get and post) are supported by the server ).

8.5 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.

8.6 expires

A condition get is returned only when the modification time is later than the specified time. Otherwise, a 304 (not modified) status is returned. When should I think the document has expired and no longer cache it.

9 Response Message example:

HTTP/1.0 200 OK

Date: Mon, 31dec200104: 25: 57gmt

Server: Apache/1.3.14 (UNIX)

Content-Type: text/html

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

Content-Length: 4359

Content-range: bytes554554-40279979/40279980

 

Response body...

 

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