HTTP request messages and HTTP response messages

Reprinted from: http://www.cnblogs.com/biyeymyhjob/archive/2012/07/28/2612910.html

HTTP messages are text-oriented, and each field in the message is a number of ASCII strings, and the length of each field is indeterminate. HTTP has two types of messages: Request messages and response messages.

HTTP request message

An HTTP request message consists of a request line, a request header (header), a blank line, and 4 parts of the request data, giving the general format of the request message.

Or

[

1. Request Header

The request line consists of 3 fields of the Request Method field, the URL field, and the HTTP protocol version field, separated by a space. For example, get/index.html http/1.1.

The HTTP protocol request method has get, POST, HEAD, PUT, DELETE, OPTIONS, TRACE, CONNECT.

And there are several common ones:

1). GET

The most common kind of request, when the client to read the document from the server, when clicked on a link on the Web page or through the browser's address bar to enter a URL to browse the Web page, the use of the Get method. The Get method requires the server to place the URL-positioned resource in the data portion of the response message, which is sent back to the client. When using the Get method, the request parameter and the corresponding value are appended to the URL, using a question mark ("?" ) represents the end of the URL and the start of the request parameter, which is limited by the length of the pass parameter. For example,/index.jsp?id=100&op=bind, so that data passed by get is directly represented in the address, so we can send the result of the request as a link to the friend. To use Google search Domety as an example, the request format is as follows:

get/search?hl=zh-cn&source=hp&q=domety&aq=f&oq= http/1.1  
Application/msword, Application/x-silverlight, Application/x-shockwave-flash, */*  Referer: <a href= "/http/ www.google.cn/">http://www.google.cn/</a>  accept-language:zh-cn  accept-encoding:gzip, deflate  user-agent:mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;. NET CLR 2.0.50727; TheWorld)  Host: <a href= "http://www.google.cn" >www.google.cn</a>  connection:keep-alive  
nid=31=ojj8d-iygaetsxlgajmqsjvhcspkvijrb6omjamnrsm8lzhky_ymfo2m4qmrkch1g0iqv9u-2hfbw7bufwvh7pgarub0rnhcju37y-
Fxlrugatx63jlv7cwmd6ub_o_r  

As you can see, requests for Get methods generally do not contain the "Request Content" section, where the request data is expressed in the form of an address in the request line. The address links are as follows:

<a href= "http://www.google.cn/search?hl=zh-CN&source=hp&q=domety&aq=f&oq=" >http:// Www.google.cn/search?hl=zh-CN&source=hp

Address "?" The next part is the request data sent through GET, we can see clearly in the address bar, each data is separated by the "&" symbol. Obviously, this is not a good way to transfer private data. Also, because different browser-to-address character restrictions are also different, generally only up to 1024 characters can be recognized, so if you need to transfer large amounts of data, it is not appropriate to use the Get method.

2). POST

For cases where the Get method is not appropriate, consider using post, because using the Post method allows the client to provide more information to the server. The Post method encapsulates the request parameter in the HTTP request data, appears as a name/value, and can transmit a large amount of data so that the post does not have a limit on the size of the data being transmitted, and it is not displayed in the URL. Also take the above search Domety as an example, if you use the Post method, the format is as follows:

Post/search http/1.1  
Application/msword, Application/x-silverlight, Application/x-shockwave-flash, */*  Referer: <a href= "/http/ www.google.cn/">http://www.google.cn/</a>  accept-language:zh-cn  accept-encoding:gzip, deflate  user-agent:mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;. NET CLR 2.0.50727; TheWorld)  Host: <a href= "http://www.google.cn" >www.google.cn</a>  connection:keep-alive  
nid=31=ojj8d-iygaetsxlgajmqsjvhcspkvijrb6omjamnrsm8lzhky_ymfo2m4qmrkch1g0iqv9u-2hfbw7bufwvh7pgarub0rnhcju37y-
Fxlrugatx63jlv7cwmd6ub_o_r  hl=zh-cn&source=hp&q=domety  

As you can see, the POST request line does not contain a data string, which is stored in the Request Content section and is separated by the "&" symbol between the data. The Post method is mostly used for pages in forms. Because post can also do get function, so most people use the Post method when designing the form, in fact, this is a misunderstanding. Get mode also has its own characteristics and advantages, we should choose whether to use Get or post according to different circumstances.

3). HEAD

Head is like a get, except that the server receives a head request and returns only the response header, without sending the response content. When we only need to look at the state of a page, the use of head is very efficient, because the content of the page is omitted during transmission.

2. Request the head

The request header consists of a keyword/value pair, one pair per line, a keyword and a value separated by a colon ":". The request header notifies the server that there is information about the client request, and the typical request headers are:

User-agent: The type of browser that generated the request.

Accept: A list of content types that the client can identify.

Host: The hostname of the request, which allows multiple domain names to be located in the same IP address as the virtual host.

3. Blank Line

The last request header is followed by a blank line that sends a carriage return and a newline character, notifying the server that the request header is no longer available.

4. Request data

The request data is not used in the Get method, but is used in the Post method. The Post method is useful for situations where a customer needs to fill out a form. The most commonly used request headers associated with request data are Content-type and content-length.

HTTP messages

The HTTP response is also made up of three parts: the status line, the message header, and the response body.

The format of the HTTP response is similar to the format of the request, as shown below:







[ ]

As you can see, the only real difference in response is that the first line uses state information instead of the request information. Status line describes the requested resource situation by providing a status code.

The status line format is as follows:

Http-version Status-code reason-phrase CRLF

Where http-version represents the version of the server HTTP protocol, Status-code represents the response status code sent back by the server, and Reason-phrase represents a textual description of the status code. The status code consists of three digits, the first number defines the category of the response, and there are five possible values.

• 1XX: Indicates that the request has been received and continues processing.
• 2XX: Success-Indicates that the request has been successfully received, understood, accepted.
• 3XX: Redirect--further action is required to complete the request.
• 4XX: Client Error--the request has a syntax error or the request is not implemented.
• 5XX: Server-side error-the server failed to implement a legitimate request.

A description of the common status code and status is described below.

• OK: Client request succeeded.
• Bad Request: Client requests have syntax errors and cannot be understood by the server.
• 401 Unauthorized: Request is not authorized, this status code must be used with the Www-authenticate header domain.
• 403 Forbidden: The server receives the request but refuses to provide the service.
• 404 Not Found: The request resource does not exist, for example: The wrong URL was entered.
• Internal Server error: Unexpected errors occurred on the server.
• 503 Server Unavailable: The server is currently unable to process client requests and may return to normal after a period of time, for example: http/1.1 OK (CRLF).

An example of an HTTP response message is given below

http/1.1 Okdate:sat, Dec 2005 23:59:59 Gmtcontent-type:text/html;charset=iso-8859-1content-length: 122    Wrox homepage   !--body goes here-->  

About the difference between get and post for HTTP requests

1.GET submission, the requested data will be appended to the URL (that is, the data placed in the HTTP protocol header ), in order to split the URL and transfer data, multiple parameters with & connection; for example: LOGIN.ACTION?NAME=HYDDD &password=idontknow&verify=%e4%bd%a0%E5%A5%BD. If the data is an English letter/number, sent as is, if it is a space, converted to +, if it is Chinese/other characters, the string is directly encrypted with BASE64, such as:%E4%BD%A0%E5%A5%BD, where the xx in%xx is the symbol in 16 binary notation ASCII.

Post submission: Place the submitted data in the package of the HTTP packet. In the example above, the red font indicates the actual transfer data

As a result, the data submitted by get is displayed in the Address bar, while the post is submitted, the address bar does not change

2. The size of the transmitted data:

First, the HTTP protocol does not limit the size of the transmitted data, nor does the HTTP protocol specification limit the URL length. The main limitations in the actual development are:

GET: Specific browsers and servers have restrictions on URL length, such as IE's limit on URL length is 2083 bytes (2k+35). For other browsers, such as Netscape, Firefox, etc., there is theoretically no length limit, and its limitations depend on the support of the operating system.

Therefore, for a get commit, the transmitted data is limited by the URL length.

POST: The theoretical data is not limited because it is not transmitted via a URL. However, the actual Web server will be required to limit the size of the post submission data, Apache, IIS6 have their own configuration.

3. Security:

The security of post is higher than the security of get. Note: The security described here is not the same concept as the "security" mentioned in get above. The meaning of "security" above is simply not to make data changes, and the meaning of security here is the meaning of true security, such as: submit data through get, user name and password will appear in plaintext on the URL, because (1) the login page may be cached by the browser, (2) Other people to view the browser's history, Then someone else can get your account number and password,

HTTP request messages and HTTP response messages