"Message" Understanding the HTTP Protocol's Request/response (request response) model

"Message" Understanding the HTTP Protocol's Request/response (request response) Model family Catalog

Introduction Request/Response model

Http://www.cnblogs.com/engraver-lxw/p/7550514.html

"principle" Understanding the HTTP Protocol's Request/response (request response) model

Http://www.cnblogs.com/engraver-lxw/p/7550691.html

　　"Message" understands the HTTP protocol's Request/response (request response) model--the current

Http://www.cnblogs.com/engraver-lxw/p/7551041.html

I. URI and URL description 1.1 URL definition

　　 HTTP uses a Uniform Resource identifier (Uniform Resource Identifiers, URI) to transfer data and establish a connection. A URL is a special type of URI that contains enough information to find a resource.
URL, full name is Uniformresourcelocator, Chinese is called the Uniform Resource Locator, is used on the Internet to identify a resource address. Take the following URL as an example to introduce the parts of the common URL:
Http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
As you can see from the URL above, a complete URL includes the following sections:
(1) Part of the agreement: the protocol portion of the URL is "http:", which means that the Web page uses the HTTP protocol. You can use multiple protocols in the Internet, such as http,ftp, and so on, in this case the HTTP protocol. "//" after "HTTP" is a delimiter
(2) Domain name part: The domain name portion of the URL is "www.aspxfans.com". A URL, you can also use the IP address as the domain name
(3) port section: followed by the domain name is the port, between the domain name and the port using ":" As the delimiter. The port is not a required part of the URL and if the port portion is omitted, the default port will be used
(4) virtual directory part: From the first "/" after the domain name to the last "/", is the virtual directory part. The virtual directory is also not a required part of the URL. The virtual directory in this example is "/news/"
(5) file name part: From the last "/" after the domain name to "?" "So far, is the file name part, if there is no"? ", then from the domain name after the last"/"Start to" # "so far, is the document part, if not"? "and" # ", then from the last"/"after the domain name to the end, is the file name section. The file name in this example is "index.asp". The file name section is also not a required part of the URL, and if omitted, the default file name is used
(6) Anchor part: From the beginning of "#" to the end, are the anchor parts. The anchor section in this example is "name". The anchor part is also not a required part of the URL
(7) Parameter section: from "? The part between start and # is the parameter part, also called the search section, the query part. In this example, the parameter section is "Boardid=5&id=24618&page=1". Parameters can be allowed to have more than one parameter, with "&" as the delimiter between parameters and parameters.
(Original: http://blog.csdn.net/ergouge/article/details/8185219)

1.2 The difference between URI and URL

　 The URI, which is the Uniform Resource identifier, is the Uniform Resource identifier used to uniquely identify a resource.
every resource available on the Web, such as HTML documents, images, video clips, programs, etc., is a URI to locate.
URIs are generally made up of three parts:
① naming mechanism for accessing resources
② host name of the storage resource
the name of the ③ resource itself, represented by a path, with emphasis on resources.
The URL is the Uniform Resource Locator, a Uniform Resource locator, which is a specific URI that the URL can use to identify a resource and also how to locate the resource.
URLs are strings used on the Internet to describe information resources, mainly used in various WWW client programs and server programs, especially the famous mosaic.
URLs can be used in a unified format to describe various information resources, including files, server addresses and directories. The URL is generally composed of three parts:
① Protocol (or service mode)
② Host IP address (sometimes including port number) for this resource
③ The specific address of the host resource. such as directory and file name, etc.
urn,uniform resource Name, Uniform Resource naming, is the identification of resources by name, such as Mailto:[email protected] com.
URIs define a Uniform resource identity in an abstract, high-level concept, whereas URLs and urns are the exact way the resource is identified. URLs and urns are all a kind of URI. Generally speaking, each URL is a URI, but not necessarily every URI is a URL. This is because the URI also includes a subclass, the Uniform Resource Name (URN), which names the resource but does not specify how to locate the resource. The mailto, News, and ISBN URIs above are examples of urns.
In the Java URI, a URI instance can represent absolute or relative, as long as it conforms to the syntax rules of the URI. The URL class not only conforms to semantics, but also contains information that locates the resource, so it cannot be relative.
In the Java class Library, the URI class does not contain any method of accessing the resource, its only function is parsing.
instead, the URL class can open a stream that reaches the resource.

Two. Message Analysis 2.1 types

　HTTP has two types of messages:
　　Request message: A request message is sent from the customer to the server.
　　Response message: from the server to the customer's answer.
Because HTTP is text-oriented, each field in the message is a number of ASCII strings, so the length of each field is indeterminate. Both the HTTP request message and the response message are made up of three parts. The difference between the two message formats is that the start line is different.
　　start line: used to distinguish between a request message or a response message. The start line in the request message is called the request line, and the start line in the response message is called the status line.
　　First line: Some information used to describe the browser, server, or message body. The header can have several lines, but it can also be used without.
　　entity Body: This field is not normally used in the request message and may not be in the response message.

2.2 Request Message

　 HTTP requests can use a variety of request methods, depending on the HTTP standard.
HTTP1.0 defines three methods of request: GET, POST, and head.
HTTP1.1 has five new request methods: Options, PUT, DELETE, TRACE, and CONNECT methods.
The GET request specifies the page information and returns the entity principal.
HEAD is similar to a GET request, except that there is no specific content in the returned response to get the header
POST submits data to the specified resource for processing requests (such as submitting a form or uploading a file). The data is included in the request body. A POST request may result in the creation of new resources and/or modification of existing resources.
PUT replaces the contents of the specified document with the data that the client transmits to the server.
the delete request server deletes the specified page.
The connect http/1.1 protocol is reserved for proxy servers that can change connections to pipelines.
The OPTIONS allows clients to view server performance.
TRACE echoes the requests received by the server, primarily for testing or diagnostics.

　　Example one: Get request example

host    img.mukewang.com
user-agent    mozilla/5.0 (Windows NT 10.0; WOW64) applewebkit/537.36 (khtml, like Gecko) chrome/51.0.2704.106 safari/537.36
accept    image/webp,image/*,*/*;q=0.8
referer    http://www.imooc.com/
accept-encoding    gzip, deflate, SDCH
ACC ept-language    zh-cn,zh;q=0.8

"Parsing" The first part: A request line that describes the type of request, the resource to be accessed, and the HTTP version used.
The Get Description request type is get,[/562f25980001b1b106000338.jpg] is the resource to be accessed, and the last part of the row illustrates the use of the HTTP1.1 version.
The second part: the request header, followed by the request line (that is, the first line) after the section, to explain the server to use additional information
From the second line to the request header, host will indicate the destination of the request. User-agent, both server-side and client script access to it, is an important basis for browser type detection logic. This information is defined by your browser and is automatically sent in each request, etc.
Part Three: blank line, a blank line behind the request header is required
Even if the request data for part four is empty, there must be a blank line.
Part IV: The request data is also called the principal, you can add any other data.
The request data for this example is empty.

　　Example two: Post request example

"Message" post/http1.1
Host:www.wrox.com
user-agent:mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;. NET CLR 2.0.50727;. NET CLR 3.0.04506.648;. NET CLR 3.5.21022)
content-type:application/x-www-form-urlencoded
Content-length:40
Connection:keep-alive

Name=professional%20ajax&publisher=wiley
"Parsing" The first part: The request line, the first line is clear is the POST request, as well as the http1.1 version.
The second part: The request head, the second line to the sixth line.
Part Three: blank line, blank line in line seventh.
Part IV: Request data, line eighth.

2.3 Response Message

　　Example one: OK
"Message" http/1.1 OK
Date:fri, 06:07:21 GMT
content-type:text/html; Charset=utf-8

<body>
<!--body goes here-->
</body>

"parsing" the first part: the status line, by the HTTP protocol version number, status code, status message three parts.
The first behavior status line, (http/1.1) indicates that the HTTP version is 1.1, the status code is 200, and the status message is (OK)
Part II: Message headers that describe some additional information that the client will use
the second line and the third behavior message header,
Date: The day and time the response was generated; Content-type: The MIME-type HTML (text/html) is specified and the encoding type is UTF-8
Part Three: blank line, a blank line after the message header is required
Part IV: The response body, the text information that the server returns to the client.
the HTML portion following the empty line is the response body.

2.4 Status Code

　　The status code consists of three digits, and the first number defines the category of the response, divided into five categories:

1XX: Indication 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--further action is required to complete the request
4XX: Client Error--Request syntax error or request not implemented
5XX: Server-side error-the server failed to implement a legitimate request

Common Status Codes:

$ OK//client request succeeded
Bad Request//client requests have syntax errors and cannot be understood by the server
401 Unauthorized//request unauthorized, this status code must be used with the Www-authenticate header field
403 Forbidden//server receives request, but refuses to provide service
404 Not Found//request resource not present, eg: wrong URL entered
Internal Server error//server unexpected errors
503 Server Unavailable//server is currently unable to process client requests and may return to normal after some time

More Status Codes http://www.runoob.com/http/http-status-codes.html

Three. Working principle

　　 The HTTP protocol defines how Web clients request Web pages from a Web server and how the server routes Web pages to clients. The HTTP protocol uses the request/response model. The client sends a request message to the server that contains the requested method, URL, protocol version, request header, and request data. The server responds with a status line that includes the version of the Protocol, the success or error code, the server information, the response header, and the response data.
The following are the steps for HTTP request/response:
(1) client connects to Web server
an HTTP client, typically a browser, establishes a TCP socket connection with the HTTP port of the Web server (default is 80). For example, http://www.oakcms.cn.
(2) sending an HTTP request
through TCP sockets, the client sends a text request message to the Web server, which consists of a request line, a request header, a blank line, and 4 parts of the requested data.
(3) The server accepts the request and returns the HTTP response
the Web server resolves the request and locates the requested resource. The server writes a copy of the resource to the TCP socket, which is read by the client. A response consists of a status line, a response header, a blank line, and a 4 portion of the response data.
(4) Releasing the connection TCP connection
If the connection mode is close, the server actively shuts down the TCP connection, the client shuts down the connection passively, releases the TCP connection, and if the connection mode is keepalive, the connection is maintained for a period of time and the request can continue to be received;
(5) client browser parsing HTML content
The client browser parses the status line first to see the status code indicating whether the request was successful. Each response header is then parsed, and the response header informs the following character sets for several bytes of HTML documents and documents. The client browser reads the response data HTML, formats it according to the syntax of the HTML, and displays it in a browser window.
For example: Type the URL in the browser address bar and press ENTER to experience the following process:
1. The browser requests the DNS server to resolve the IP address of the domain name in the URL;
2, after resolving the IP address, according to the IP address and the default port 80, and the server to establish a TCP connection;
3, the browser issued a read file (the URL in the back part of the corresponding file) HTTP request, the request message as a TCP three handshake third message data sent to the server;
4, the server responds to the browser request, and the corresponding HTML resulting sent to the browser;
5, release the TCP connection;
6, the browser will be the HTML text and display content.

Four. State management

　　 as mentioned earlier, the HTTP protocol is stateless and cannot hold information for each commit, that is, when the server returns a response corresponding to the request, all information about the transaction is discarded. If a user sends a new request, the server cannot know if it is associated with the last request.
This is a good feature for simple static HTML files, but it is problematic for web operations such as shopping carts that need to be submitted more than once in a friendly way. The server-side Web application must allow the user to complete the entire purchase of the item through multiple steps. In this case, the application must keep track of the information provided by multiple requests made by the same browser, remembering the user's trading status.
Generally, there are two ways to solve this problem. The first is to return the full state in each response, allowing the browser to send it back as part of the next request. The second is to save the state somewhere on the server, send back only an identifier, the browser in the next commit and then send the identifier back, so that you can locate the stored on the server state information.
In both methods, information can be sent to the browser in one of the following three ways: As a cookie, embedded in an HTML form as a hidden field, attached to the URL of the principal (usually as a link to another application page, URL rewrite).
A cookie is a name/value pair that the server sends to the browser in the reply message. The browser saves these cookies, and the duration of the save is determined by the cookie's expiration attributes. When the browser sends a request to the server, it checks the cookie settings and injects all the cookies it receives from the same server into the request information. Using cookies is an easy way to deal with state issues, but not all browsers support it, and users may also disable cookies.
If you use a hidden field in an HTML form to send state information to the browser, the browser will return the information to the server as a regular HTTP parameter when the form is submitted. When the status information is injected into the URL, it is routed to the server as part of the request URL.
It is not an efficient way to transfer all state information back and forth between the browser and the server, so most servers choose to keep the information on the server and only pass an identifier between the browser and the server. This is known as session tracking. All requests from the browser that contain the same identifier (this is the session ID) belong to one session, and the server keeps track of all information about the session. The session is valid until it is explicitly aborted, or when the user has no action for a period of time, the server is automatically set to expire. There is currently no way to inform the server that the user has closed the browser because there is no persistent connection between the browser and the server, and no messages are sent to the server when the browser is closed. Also, closing a browser usually means that the session ID is missing, the cookie expires, or the URL that injects the message is no longer available. Therefore, when the user opens the browser again, the server cannot connect the new request to the previous session, and can only create a new session. However, all data related to the previous session persists on the server until the session expiration is cleared.

Appendix A the difference between get and post requests

GET request
Get/books/?sex=man&name=professional http/1.1
Host:www.wrox.com
user-agent:mozilla/5.0 (Windows; U Windows NT 5.1; En-us; rv:1.7.6)
gecko/20050225 firefox/1.0.1
Connection:keep-alive
Note that the last line is a blank line
POST request
post/http/1.1
Host:www.wrox.com
user-agent:mozilla/5.0 (Windows; U Windows NT 5.1; En-us; rv:1.7.6)
gecko/20050225 firefox/1.0.1
content-type:application/x-www-form-urlencoded
Content-length:40
Connection:keep-alive

Name=professional%20ajax&publisher=wiley
(1) Get commit, 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 of all: the HTTP protocol does not limit the size of the transmitted data, and the HTTP protocol specification does not limit the length of the URL.
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. For example: Through get submit data, 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 others can get your account number and password, in addition, Using get to submit data may also cause Cross-site request forgery attack
(4) The HTTP GET,POST,SOAP protocol is run on HTTP
(4.1) Get: Request parameter is the length of the query string attached to the URL as a sequence of key/value pairs (query string) is limited by Web browsers and Web servers (such as IE supports up to 2048 characters) and is not suitable for transporting large datasets at the same time, it is unsafe
(4.2) Post: The request parameter is transmitted in a different part of the HTTP header (named entity body), which is used to transfer the form information, so the Content-type must be set to: application/x-www-form- Urlencoded. The post is designed to support user fields on Web Forms, and its parameters are also transmitted as key/value.
However: it does not support complex data types, because post does not define the semantics and rules for transferring data structures.
(4.3) Soap: is a dedicated version of HTTP POST, followed by a special XML message format
Content-type is set to: Text/xml Any data can be XML.
The HTTP protocol defines a number of ways to interact with the server, the most basic of which are 4, get,post,put,delete, respectively. A URL address is used to describe a resource on a network, and the Get, POST, PUT, delete in HTTP corresponds to the search for this resource, change, increase, delete 4 operations. Our most common is get and post. Get is typically used to get/query resource information, and post is typically used to update resource information.

Summary of Get and post differences:
A.get submitted data will be placed after the URL, to split the URL and transfer data, the parameters are connected to &, such as editposts.aspx?name=test1&id=123456. The Post method is to put the submitted data in the body of the HTTP packet.
There is a limit to the size of data submitted by B.get (because the browser has a limit on the length of the URL), and there is no limit to the data submitted by the Post method.
The C.get method needs to use Request.QueryString to get the value of the variable, and the Post method takes the value of the variable by Request.Form.
D.get Way to submit data, it will bring security issues, such as a login page, through the Get method to submit data, the user name and password will appear on the URL, if the page can be cached or other people can access the machine, you can obtain the user's account and password from the history.

-If there is a wrong place, very welcome to give guidance!

--"Thanks" data source http://blog.csdn.net/vosamo007/article/details/49684603

--"Thanks" data source http://blog.csdn.net/dzweather/article/details/51284149

--"Thanks" data source http://blog.csdn.net/huan_mie/article/details/6092469

--"Thanks" data source http://www.cnblogs.com/pingguohua/articles/687856.html

--"Thanks" data from http://www.cnblogs.com/ranyonsue/p/5984001.html

"message" Understanding the HTTP Protocol's Request/response (request response) model