Http protocol for Tomcat Learning

As a Web application server, Tomcat mainly responds to the request data from the client (browser). The most common one is to use HTTP protocol to complete customer interaction. Therefore, we should consolidate the HTTP protocol knowledge before further learning Tomcat.

HyperText Transfer Protocol (Hyper Text Transfer Protocol) is a Transfer Protocol used to Transfer HyperText from a WWW server to a local browser. It makes the browser more efficient and reduces network transmission. It not only ensures that the computer transfers hypertext documents correctly and quickly, but also determines which part of the transmitted documents and which part of the content is first displayed (such as text before graphics. The default HTTP port number is 80. In our own applications, we usually modify this port number as needed.

1. HTTP Request Response Model

The HTTP protocol always initiates a request from the client, and the server returns the response. See:

Therefore, when the client does not initiate a request, the server pushes the message to the client. At the same time, HTTP is a stateless protocol. This request of the same client does not correspond to the previous request, so it does not save the data content last transmitted for the client, if the server still needs the data for the next request, it can only be re-transmitted.

2. Workflow

An HTTP operation is called a transaction. The procedure can be divided into four steps:

1) First, the client and the server need to establish a connection. Click a hyperlink to start HTTP.

2) After a connection is established, the client sends a request to the server in the format of Uniform Resource Identifier (URL), Protocol version number, the MIME information is followed by the request modifier, client information, and possible content.

3) after receiving the request, the server returns the corresponding response information in the format of a status line, including the Protocol version number of the information, a successful or wrong code, MIME information is followed by server information, entity information, and possible content.

4) The information returned by the client receiving server is displayed on the user's display screen through a browser, and the client is disconnected from the server.

If an error occurs in one of the preceding steps, the error message is returned to the client and displayed. For users, these processes are completed by HTTP. Common users only need to click and wait for the information to be displayed.

When you are learning the http protocol, you can use httpWatch, wireShark, and other packet capture tools to capture packets. Then, you can combine the captured data with the http knowledge to better understand the situation.

3. http URL

The format of http url (a URL is a special type of URI that contains sufficient information for searching a resource) is as follows:
Http: // host [":" port] [abs_path]
Http indicates that network resources are to be located through the HTTP protocol; host indicates a valid Internet host domain name or IP address; port specifies a port number. If it is null, the default port 80 is used; abs_path specifies the URI of the requested resource. If abs_path is not provided in the URL, it must be given in the form of "/" when it is used as the request URI. Generally, this work is automatically completed by the browser.

Eg:
1. Enter www.guet.edu.cn
The browser automatically converts to: http://www.guet.edu.cn/

The http protocol is based on the request-response mode, which means that a communication includes at least two parts: request and response.

4. http-client requests

An http request consists of three parts: the request line, the message header, and the request body. This is the header information of an http request.

Figure 1

Request Line

The request line starts with a method symbol and is separated by spaces, followed by the requested URI and Protocol Version. The format is as follows: MethodRequest-uri http-Version CRLF. The first line in Figure 1 is the request line information.

The Method indicates the Request Method, the Request-URI is a unified resource identifier, the HTTP-Version indicates the HTTP protocol Version of the Request, and the CRLF indicates the carriage return and line feed (except for the CRLF as the end, separate CR or LF characters are not allowed)

There are multiple request methods (all methods are capitalized). The common methods are described as follows:
GET Request to GET the resource identified by Request-URI
POST attaches new data to the resource identified by Request-URI
HEAD Request to obtain the Response Message Header of the resource identified by Request-URI
The PUT Request server stores a resource and uses Request-URI as its identifier.
The DELETE Request server deletes the resource identified by Request-URI.
TRACE Request information received by the server for testing or diagnosis
CONNECT reserved for future use
OPTIONS requests query server performance, or query resource-related OPTIONS and requirements

5. http Server Response

Figure 2

After receiving and interpreting the request message, the server returns an HTTP Response Message.

HTTP response is also composed of three parts: Status line, message header, response body such as 2
1. The status line format is as follows:
HTTP-Version Status-Code Reason-Phrase CRLF
HTTP-Version indicates the HTTP protocol Version of the server, Status-Code indicates the response Status Code sent back by the server, and Reason-Phrase indicates the text description of the Status Code.
The status code consists of three numbers. The first number defines the response category and has five possible values:
1xx: indicates that the request has been received and continues to be processed.
2xx: Success-indicates that the request has been successfully received, understood, and accepted
3xx: Redirection-further operations are required to complete the request
4xx: client error-the request has a syntax error or the request cannot be implemented
5xx: Server Error -- the server fails to fulfill the valid 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 currently and may return to normal after a period of time
Eg: HTTP/1.1 200 OK (CRLF)

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

 

Message Header

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. Common Header
In a common header, there are a few header fields used for all request and response messages, but not for transmitted entities, only for transmitted messages.
Eg:
Cache-Control is used to specify Cache commands. Cache commands are unidirectional (Cache commands in the response may not appear in the request ), it is independent (the cache command of one message does not affect the cache mechanism of the other message processing), and the similar header domain used by HTTP1.0 is Pragma.
Cache commands for requests include: no-cache (used to indicate that the request or response message cannot be cached), no-store, max-age, max-stale, min-fresh, only-if-cached;
Cache commands for response include public, private, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, max-age, and s-maxage.
For example, to instruct the IE browser (client) Not to Cache pages, the Server JSP program can be written as follows: response. sehHeader ("cache-Control", "no-Cache ");
// Response. setHeader ("Pragma", "no-cache"); equivalent to the above Code, usually both //
This Code sets the common header domain: Cache-Control: no-cache in the sent response message.
Date common header field indicates the Date and time of message generation

The Connection common header field allows sending the specified Connection option. For example, if the specified connection is continuous or the "close" option is specified, a notification is sent to the server. After the response is complete, the connection is closed.

The request header allows the client to send additional request information and client information to the server. In Figure 1, the rows below the first line are request message headers.

Common request headers
Accept
The Accept request header field is used to specify the types of information the client accepts. Eg: Accept: image/gif indicates that the client wants to Accept resources in the GIF image format; Accept: text/html indicates that the client wants to Accept html text.
Accept-Charset
The Accept-Charset request header field is used to specify the character set accepted by the client. Eg: Accept-Charset: iso-8859-1, gb2312. if this field is not set in the request message, it is acceptable by default for any character set.
Accept-Encoding
The Accept-Encoding Request Header domain is similar to Accept, but it is used to specify acceptable content Encoding. Eg: Accept-Encoding: gzip. deflate. If the domain server is not set in the request message, it is assumed that the client can Accept all content Encoding.
Accept-Language
The Accept-Language Request Header domain is similar to Accept, but it is used to specify a natural Language. Eg: Accept-Language: zh-cn. If this header field is not set in the request message, the server assumes that the client is acceptable to all languages.
Authorization
The Authorization request header domain is used to prove that the client has the right to view a resource. When a browser accesses a page, if the response code of the server is 401 (unauthorized), it can send a request containing the Authorization request header domain, requiring the server to verify the request.
Host (this header field is required when a request is sent)
The Host request header field is used to specify the Internet Host and port number of the requested resource. It is usually extracted from the http url. For example:
We enter: http://www.guet.edu.cn/index.html in the browser
The request message sent by the Browser contains the Host Request Header domain, as follows:
Host: www.guet.edu.cn
The default port number is 80. If the port number is specified, it is changed to: Host: www.guet.edu.cn: the specified port number.
User-Agent
When we log on to the forum online, we will often see some welcome information, which lists the names and versions of your operating system, the names and versions of your browsers, this is often amazing for many people. In fact, the server application obtains this information from the User-Agent Request Header domain. The User-Agent request header field allows the client to tell the server its operating system, browser, and other attributes. However, this header field is not required. If we write a browser and do not use the User-Agent to request the header field, the server will not be able to know our information.

3. Response Header
The Response Header allows the server to transmit additional response information that cannot be placed in the status line, as well as information about the server and the next access to the resource identified by the Request-URI.
Common Response Headers
Location
The Location response header field is used to redirect the receiver to a new Location. Location response header fields are often used when domain names are changed.
Server
The Server response header contains the software information used by the Server to process requests. It corresponds to the User-Agent Request Header domain. Below is
An example of the Server response header domain:
Server: Apache-Coyote/1.1
WWW-Authenticate
The WWW-Authenticate Response Header domain must be included in the 401 (unauthorized) Response Message. When the client receives the 401 Response Message and sends the Authorization Header domain request server to verify the message, the server response header contains this header field.
Eg: WWW-Authenticate: Basic realm = "BasicAuth Test! "// You can see that the server uses a basic authentication mechanism for requested resources.

4. Object Header
Both request and response messages can be transmitted as an entity. An object consists of the object header domain and the Object Body, but it does not mean that the object header domain and the Object Body must be sent together, but only the object header domain can be sent. The object header defines metadata about the Object Body (eg: whether there is an entity body) and the resource identified by the request.
Common Object Headers
Content-Encoding
The Content-Encoding object header field is used as a modifier of the media type. Its value indicates the Encoding of additional Content that has been applied to the Object Body, to obtain the media types referenced in the Content-Type header field, the corresponding decoding mechanism must be adopted. Such as Content-Encoding, which is used to record the File compression method, eg: Content-Encoding: gzip
Content-Language
The Content-Language object header field describes the natural Language used by the resource. If this field is not set, the entity content will be provided to all languages for reading.
. Eg: Content-Language: da
Content-Length
The Content-Length object header field is used to specify the Length of the Object Body, which is represented by a decimal number stored in bytes.
Content-Type
The Content-Type object header field specifies the media Type of the Object Body sent to the recipient. Eg:
Content-Type: text/html; charset = ISO-8859-1
Content-Type: text/html; charset = GB2312
Last-Modified
The Last-Modified object header field is used to indicate the Last modification date and time of the resource.
Expires
The Expires object header field specifies the response expiration date and time. To enable the proxy server or browser to update the cache after a period of time (when accessing the previously visited page again, load the page directly from the cache, shorten the response time and reduce the server load, we can use the Expires object header field to specify the page expiration time. Eg: Expires: Thu, 15 Sep 2006 16:23:12 GMT
The client and cache of HTTP1.1 must regard other illegal date formats (including 0) as expired. Eg: to prevent the browser from caching pages, we can also use the Expires object header field to set it to 0. The jsp program is as follows: response. setDateHeader ("Expires", "0 ");

 

Refer:

Http://www.cnblogs.com/li0803/archive/2008/11/03/1324746.html

Http://www.blogjava.net/zjusuyong/articles/304788.html

HTTP protocol (RFC2616) Chinese Version

Previous Article: catalina. bat

Next article: Socket in Tomcat's learning process