HTTP request and Response mode

HTTP request Format

When the browser makes a request to the Web server, it passes a block of data to the server, which is the request information, and theHTTP request information consists of 3 parts:

L Request method URI protocol /version

L Requests Header ( request header)

L Request Body

The following is an example of an HTTP request:

get/sample.jsphttp/1.1

accept:image/gif.image/jpeg,*/*

Accept-language:zh-cn

Connection:keep-alive

Host:localhost

user-agent:mozila/4.0 (compatible; MSIE5.01; Window NT5.0)

Accept-encoding:gzip,deflate

username=jinqiao&password=1234

(1) Request method URI protocol /version

The first line of the request is "method URL Negotiation /version":get/sample.jsp http/1.1

In the code above, "GET" represents the request method, "/sample.jsp" represents the URI, "http/1.1 represents the version of the Protocol and Protocol."

HTTP requests can use a variety of request methods, depending on the HTTP standard. For example:HTTP1.1 currently supports 7 methods of request:GET,POST,HEAD,OPTIONS,PUT, delete,and Tarce.

But in fact we use only get and post in most cases. These six methods are used if you want to design a Web application that is compliant with restful specifications. But even if you don't want to involve rest for the time being, understanding the nature of these six methods is still very useful. You will find that the web is also very concise and clear. The following six methods are described in turn.

The
• Get:get can be said to be the most common, essentially sending a request to get a resource on the server. Resources are returned to the client through a set of HTTP headers and rendering data (such as HTML text, or pictures or videos). In a GET request, the rendering data is never included. The
• Head:head is the same as get essence, except that the head does not contain rendering data, but only the HTTP header information. Some people may find this method useless, but that is not the case. Imagine a business scenario: to determine whether a resource exists, we usually use get, but the head here is more explicit.
• PUT: This method is relatively rare. This is not supported by HTML forms. In essence, put and post are very similar, are sending data to the server, but there is an important difference between them, put usually specifies the location of the resources, and post is not, post data storage location by the server itself. For example, a url,/addblog for submitting a blog post. If put, the submitted URL will be "/addblog/abc123" like this, where abc123 is the address of the blog post. If you use post, the address will be communicated to the client by the server after submission. Most blogs are like this at the moment. Obviously, the put and post uses are not the same. The specific use depends on the current business scenario.
• Delete: Deletes a resource. This is mostly rare, but there are some places like Amazon's S3 cloud service that use this method to delete resources.
• POST: Submits data to the server. This method is widely used, and almost all of the current submissions are done by this.
• OPTIONS: This method is interesting, but rarely used. It is used to get the methods supported by the current URL. If the request succeeds, it contains a header named "Allow" in the HTTP header, which is the supported method, such as "GET, POST."
• There is actually a trace method, but this is basically not used, this is not introduced here.

The URI completely specifies the network resource to be accessed, usually with a relative directory relative to the root of the server, always beginning with a "/", and finally, the version of the Protocol that declares the use of HTTP during communication.

(2) Requesting header ( request header)

The request header contains many useful information about the client environment and the request body. For example, the request header can declare the language used by the browser, the length of the request body, and so on.

accept:image/gif.image/jpeg.*/*

Accept-language:zh-cn

Connection:keep-alive

Host:localhost

user-agent:mozila/4.0 (Compatible:msie5.01:windows NT5.0)

Accept-encoding:gzip,deflate.

(3) Request Body

Between the request header and the request body is a blank line, which is very important, which indicates that the request header has ended, followed by the request body. The request body can contain query string information submitted by the customer:

username=jinqiao&password=1234

In the HTTP request for the example above , the body of the request has only one line of content. Of course, in real-world applications, theHTTP request body can contain more content.

HTTP request method I only discuss the Get method with the post method here

L Get method

The Get method is the default HTTP request method, and we routinely use the get method to submit form data, but the form data submitted with the Get method is simply encoded, and it is sent to the Web server as part of the URL, so If you use the Get method to submit form data, there is a security risk. For example

Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=%cc%E+%BD%BB

From the URL request above, it is easy to identify what the form submits. （？ ) In addition, because the data submitted by the Get method is part of the URL request, the amount of data submitted cannot be too large

L POST method

The Post method is an alternative to the Get method, which is primarily to submit form data to the Web server, especially large batches of data. The Post method overcomes some of the drawbacks of the Get method. when submitting form data through the Post method, the data is not sent as part of the URL request but as standard data to the Web server, which overcomes the drawback that the information in the Get method is not confidential and the amount of data is too small. Therefore, for security reasons and respect for user privacy, the Post method is usually used for form submission .

From a programmatic point of view, if a user submits data through a GET method, the data is stored in the query_string environment variable, and the data submitted by the Post method can be obtained from the standard input stream.

HTTP response Format

HTTP replies are similar to HTTP requests, andHTTP responses are made up of 3 parts, namely:

L Status Line

L Response Header (Response header)

L Response Body

After the request message is received and interpreted, the server returns an HTTP response message.

The status line consists of the Protocol version, the status code in the number form, and the corresponding status description, separated by a space between the elements.

Format : http-version status-code reason-phrase CRLF

Example : http/1.1 OK \ r \ n

Status code:

The status code consists of 3 digits that indicate whether the request is understood or is satisfied.

Status Description:

The status description gives a short textual description of the status code.

The first number of the status code defines the category of the response, and the following two bits do not have a specific classification.

The first number has five possible values:

-1XX: Indicates information-Indicates that the request has been received and continues processing.

-2xx: Success-Indicates that the request has been successfully received, understood, accepted.

-3xx: Redirect-A further action must be made to complete the request.

-4xx: Client Error-The request has a syntax error or the request cannot be implemented.

-5xx: Server-side error-the server failed to implement a legitimate request.

Status Code Status Description description

OK Client Request succeeded

The bad request is not understood by the server because of a syntax error in client requests.

401 Unauthonzed request is not authorized. This status code must be used with the Www-authenticate header field

The 403 Forbidden server received the request but refused to provide the service. The server typically gives reasons for not serving in the response body

404 Not Found The requested resource does not exist, for example, the wrong URL was entered.

The Internal server error server has unexpected errors that could result in the client's request not being completed.

The 503 Service unavailable server is currently not able to process client requests, and the server may return to normal after a certain period of time.

Response header

The response header may include:

Location:

The Location response header field is used to redirect the recipient to a new position. For example: the client requested the page no longer exists in the original location, in order to redirect the client to the new location of this page, the server can send back to the address of the response header after the use of redirection statements, let the client access to the new domain name corresponding to the resources on the server. When we use the redirect statement in the JSP, the server side sends back the response header to the client, and there is a location response header field.

Server:

The server Response header field contains the software information that the server uses to process the request. It corresponds to the user-agent request header domain, which sends information about the server-side software, which sends the client software (browser ) and the operating system. The following is an example of the Server response header field:server:apache-coyote/1.1

Www-authenticate:

The Www-authenticate response header field must be contained in a 401 (unauthorized ) response message, and the header domain is related to the authorization Request header field mentioned earlier when the client receives a 401 response message, Decide whether to request the server to validate it. If the server is required to validate it, a request containing the authorization header domain can be sent, and here is An example of the Www-authenticate response header field:www-authenticate:basic realm= "Basic Auth test!"

From this response header domain, you can know that the server side is using the Basic authentication mechanism for the resources we request.

Content-encoding:

The Content-encoding Entity header field is used as the modifier for the media type, and its value indicates the additional content encoding that has been applied to the entity body, so the corresponding decoding mechanism must be used to obtain the media type referenced in the Content-type header domain. content-encoding The main terms of the document compression method, here is an example: content-encoding:gzip. If an entity body is stored in an encoded manner, it must be decoded before it is used.

Content-language:

The Content-language Entity header field describes the natural language used by the resource. Content-language allows users to identify and differentiate entities according to their preferred language. If the entity content is intended only for Danish readers, the Entity header field can be set as follows:Content-language:da.

If the content-language header field is not specified, then the entity content is provided to the reader of the language.

Content-length:

The Content-length Entity header field is used to indicate the length of the body, expressed as a decimal number stored in bytes, that is, a numeric character occupies one byte and is transmitted using its corresponding ASCII code storage.

Note that this length is only the length of the entity body and does not include the length of the entity header.

Content-type

The Content-type Entity header field term indicates the media type that is sent to the recipient's entity body. For example:

Content-type:text/html;charset=iso-8859-1

content-type:text/html;charset=gb2312

Last-modified

The Last-modified Entity header field is used to indicate the last modification date and time of the resource.

Expires

The Expires Entity header field gives the date and time when the response expires. Typically, a proxy server or browser caches some pages. When the user accesses these pages again, it is loaded directly from the cache and displayed to the user, which shortens the response time and reduces the load on the server. In order for the proxy server or browser to update the page after a period of time, we can use the Expires Entity header field to specify when the page expires. When the user accesses the page again, if the date and time given by the Expires header field are earlier (or the same) than the date and time given by the date normal header field , then the proxy server or browser will no longer use the cached page but instead request the updated page from the server. Note, however, that even if the page expires, it does not mean that the original resource on the server has changed before or after this time.

The date and time used by the expires Entity header field must be a date format in RFC 1123, for example:

Expires:thu, Sep 2005 16:00:00 GMT

The HTTP1.1 client and cache must treat other illegal date formats (also including 0) as expired. For example, to let the browser do not cache the page, we can also take advantage of the Expires Entity header field, set its value to 0, as follows (JSP):response.setdateheader ("Expires", 0);

The following is an example of an HTTP response:

http/1.1 OK

Server:apache tomcat/5.0.12

date:mon,6oct2003 13:23:42 GMT

content-length:112

HTTP request and Response mode