Principles of HTTP protocol in Android network programming (2)

1 Introduction

To understand the principles of the HTTP protocol, it is necessary to talk about HTTP messages. HTTP messages are text-oriented. Each field in the message is an ASCII string, and the length of each field is uncertain. There are two types of HTTP messages: request messages and response messages. Before understanding the HTTP message, you can use the packet capture tool to view the request message and response message of the requesting network. The packet capture tool recommends Fiddle or Charle . For example, after we visit http://msdn.itellyou.cn/ in the browser , and then capture the packet through Fiddler, we can see the request message and response message as shown below.

2 HTTP request message

An HTTP request message consists of four parts: request line, request header, blank line and request data. The general format is shown below.

Request line

The request line consists of the request method field, URI field, and HTTP protocol version field, separated by spaces. The format is: Method Request-URI HTTP-Version CRLF. As shown in the above figure: GET http://msdn.itellyou.cn/ HTTP / 1.1.

Method  indicates the request method. There are various request methods, as shown below.

GET: Request to obtain the resource identified by the Request-URI.

POST: append new data after the resource identified by the Request-URI.

HEAD: Request to get the response message header of the resource identified by the Request-URI.

PUT: Request the server to store a resource and use Request-URI as its identifier.

DELETE: Request the server to delete the resource identified by the Request-URI.

TRACE: The request server sends back the received request information, which is mainly used for testing or diagnosis.

CONNECT: The HTTP 1.1 protocol is reserved for proxy servers that can change the connection to a pipeline.

OPTIONS: Request to query the performance of the server, or to query options and requirements related to resources.

PATCH: The entity contains a table that explains the difference from the original content represented by the URI.

MOVE: Request the server to move the specified page to another network address.

COPY: Request the server to copy the specified page to another network address.

LINK: request the server to establish a link relationship.

UNLINK: Disconnect the link.

WRAPPED: allows the client to send encapsulated requests.

Extension-mothed: Additional methods can be added without changing the protocol.

Request-URI is a uniform resource identifier.

HTTP-Version indicates the requested HTTP protocol version

CRLF stands for carriage return and line feed (except for the CRLF at the end, no separate CR or LF characters are allowed).

Request header

After the request line, there will be 0 or more request headers, each request header contains a name and a value, and they are separated by an English colon ":". See the introduction of the header below for details.

Blank line

After the last request header is a blank line, a carriage return and a line feed, notifying the server that there is no longer a request header.

Request data

Request data is generally used for requests in the POST method. The POST method is suitable for occasions that require users to fill out forms. The most commonly used request headers are Content-Type and Content-Length.

3 HTTP response message

After receiving and interpreting the request message, the server will return an HTTP response message. The HTTP response message consists of 4 parts: status line, message header, blank line, and response body. The general format is shown below.

Status line

The status line consists of the HTTP protocol version, response status code, and text description fields of the status code, separated by spaces. The format is: HTTP-Version Status-Code Reason-Phrase CRLF. As shown in the figure above: HTTP / 1.1 200 OK.

Status-Code represents the response status code. It consists of 3 digits. The first digit defines the category of the response and has the following 5 possible values:

100 ~ 199: Indication message, request is received, the requester needs to continue to perform operations.

200 ~ 299: The request was successful. The request has been successfully received and processed.

300 ~ 399: Redirection. To complete the request, further operations must be performed.

400 ~ 499: Client error, the request has a syntax error or the request cannot be fulfilled.

500 ~ 599: Server error, the server cannot fulfill the legitimate request.

 

The most common status codes and status descriptions:

200 OK: The client request was successful.

400 Bad Request: The client request has a syntax error that the server cannot understand.

401 Unauthorized: The request is unauthorized. This status code must be used with the WWW-Authenticate header field.

403 Forbidden: The server receives the request, but refuses to provide the service.

500 Internal Server Error: Internal server error, unable to complete the request.

503 Server Unavailable: The server is currently unable to process client requests. It may return to normal after a period of time.

 

For more status codes, see the HTTP status code comparison table .

Response header

Like the request header, each response header contains a name and a value, separated by an English colon ":". See the introduction of the header below for details.

Blank line

After the last response header is a blank line, carriage return and line feed.

Response body

The response body is the content of the resource returned by the server.

4 Header

HTTP message headers are divided into general headers, request headers, response headers, and entity headers. They consist of key-value pairs, one pair per line, and the header field name and value are separated by a colon ":" in English. The header field name is case-insensitive. The header describes the properties of the client or server, the resources being transmitted, and the connection that should be made.

Common header

The generic header can be used in both request registration and response headers. such as:

Date: indicates the date and time when the message was generated.

Connection: Allows you to send options for specifying the connection, such as specifying whether the connection is continuous, or specifying the close option to notify the server to close the connection after the response is complete.

Cache-Control: Used to specify the cache instruction. The cache instruction is unidirectional (the cache instruction that appears in the response may not appear in the request) and is independent (the cache instruction of one message does not affect the cache of another message processing mechanism).

Request header

The request header is to allow the client to pass information about itself and the desired response form. It notifies the server about the client's request. A typical request header is shown below.

Host: The requested host name, allowing multiple domain names to be in the same IP address, that is, a virtual host.

User-Agent: information such as the browser type and operating system that sent the request.

Accept: A list of content types that can be recognized by the client to specify what types of information the client receives.

Accept-Encoding: Data encoding recognized by the client.

Accept-Language: indicates the language type supported by the browser.

Connection: Allows the client and server to specify options related to the request / response connection. For example, Keep-Alive at this time means to keep the connection.

Transfer-Encoding: Inform the receiver of what encoding method was used to ensure reliable transmission of the message.

Response header

The response header is used by the server to pass its own response information. A typical response header is shown below.

Location: Used to redirect the recipient to a new location, often used when changing domain names.

Server: Contains system information used by the server to process requests, and corresponds to the User-Agent request header.

Entity header

Entity headers are used to define the information of the transmitted resources. They can be used for both requests and responses. Both request and response messages can transmit an entity. A typical entity header is shown below.

Content-Type: The media type of the entity body sent to the recipient.

Content-Lenght: used to indicate the length of the entity body, expressed as a decimal number stored in bytes.

Content-Language: Describes the natural language used by the resource. If this option is not set, the entity content will be provided for all language reading.

Content-Encoding: Used as a modifier for media types. Its value indicates the encoding of additional content that has been applied to the body of the entity, so to obtain the media type referenced in the Content-Type header field, the corresponding decoding mechanism must be used.

Last-Modified: Used to indicate the last modified date and time of the resource.

Expires: Used to give the date and time when the response expires.

 

For more information about the introduction of headers, see the HTTP response header and request header information comparison table .

 

 

 

Published 106 original articles · praised 37 · 80,000 views

Guess you like

Origin blog.csdn.net/lyz_zyx/article/details/96326794