Http get post

I. Differences of principles

Generally, you can enter a URL in your browser to access resources by using the get method. In form submission, you can specify the submission method as get or post. The default method is get submission.

HTTP defines different methods for interacting with the server. There are four basic methods:Get, post, put, delete

The full name of a URL is a resource descriptor. We can think of it as: a URL address, which is used to describe resources on a network, while get, post, put, delete corresponds to the query, modify, add, and delete operations on this resource. Here, you should have a rough understanding. Get is generally used to obtain/query resource information, while post is generally used to update resource information (I personally think this is the essential difference between get and post, and it is also the intention of the Protocol designer. Other differences are the differences in specific forms.).

According to the HTTP specification, get is used to obtain information, and should be secure and idempotent.

1. The so-called security means that this operation is used to obtain information rather than modify information. In other words, get requests generally do not have side effects. That is to say, it only obtains the resource information, just like the database query. It does not modify, add data, and does not affect the resource status.

* Note: security only indicates that the information is not modified.

2. idempotence means that multiple requests to the same URL should return the same result. Here I will explain it again.IdempotenceThis concept:

　　 Idempotence(Idempotent, idempotence) is a mathematical or computer concept, common in abstract algebra.
Idempotence has the following definitions:
For a single-object operation, if an operation is performed multiple times for all the numbers in the range, the result is the same as that obtained once, this operation is called idempotent. For example, an absolute value operation is an example. In a real number set, ABS (A) = ABS (a) is used )).
For binary operations, it is required that when the two values involved in the calculation are equivalent, if the calculation result is equal to the two values involved in the calculation, the operation is called the idempotence, for example, a function that calculates the maximum values of two numbers has the power in the real number set, that is, Max (x, x) = x.

After reading the above explanation, you should be able to understand the meaning of the get power.

However, in practice, the above two rules are not so strict. Example of referencing others' articles: for example, the front pages of news sites are constantly updated. Although the second request will return a different batch of news, this operation is still considered safe and idempotent because it always returns the current news. Basically, if the target is to open a link, the user can be sure that the resource is not changed from his own perspective.

According to the HTTP specification, post indicates a request that may modify resources on the server. Continue to reference the above example: for news websites, readers should post their comments on news, because the Site Resources are different after the comments are submitted, or the resource is modified.

The above describes some of the principles of get and post in the HTTP specification. However, in practice, many people fail to follow the HTTP specification, which leads to many reasons, such:

1. Many users are greedy and convenient. Get is used to update resources, because form is required for post, which may cause a little trouble.

2. You can add, delete, modify, and query resources through get/post without using put and delete.

3. In the early stage, Web MVC Framework designers did not consciously view and design URLs as abstract resources. Another serious problem is that the traditional Web MVC framework basically only supports the get and post HTTP methods, rather than the put and delete methods.

* MVC: MVC originally exists in the desktop program, M is the exponential data model, V is the user interface, and C is the controller. The purpose of using MVC is to separate the implementation code of M and V, so that the same program can use different expressions.

The above three points are a typical description of the old style (not strictly compliant with HTTP specifications). With the development of the architecture, there is now a representational state transfer and a new style that supports HTTP specifications, for more information, see restful Web Services.

2. Differences in Forms

After clarifying the differences between the two principles, let's take a look at the differences in their actual application:

To understand the differences between the two during transmission, Let's first look at the HTTP protocol format:

HTTP request:

<Request line>

<Headers>

<Blank line>

<Request-body>]

In an HTTP request, the first line must be a request line to describe the request type, resources to be accessed, and the HTTP Version Used. Next is a header section, which describes additional information to be used by the server. After the header is a blank line, you can add any other data [called the body].

Example of get and post methods:
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

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
(---- Null Line here ----)
Name = Professional % 20 Ajax & publisher = Wiley

 

With the above understanding and examples of HTTP requests, let's look at the differences between the two submission methods:

(1) When a GET request is submitted, the request data will be appended to the URL (that is, the data will be placed in the request line? Splits the URL and transmits data. Multiple parameters are connected with &. For example, login. Action? Name = hyddd & Password = idontknow & verify = % E4 % BD % A0 % E5 % a5 % BD. The URL encoding format uses ASCII code rather than Unicode. That is to say, you cannot include any non-ASCII characters in the URL. All non-ASCII characters must be encoded before transmission, for URL encoding, see http://kb.cnblogs.com/page/133765 /.

Post submission: place the submitted data in the packet body of the http package. In the preceding example, the red font indicates the actual data transmission.

Therefore, the data submitted by get will be displayed in the address bar, while the address bar will not change when the post is submitted.

(2) Size of transmitted data: first, it is declared that the HTTP protocol does not limit the size of transmitted data, and the HTTP protocol does not limit the URL length.

In actual development, the following restrictions exist:

Get: the URL length of a specific browser or server is limited. For example, the URL Length of IE is limited to 2083 bytes (2 k + 35 ). For other browsers, such as Netscape and Firefox, there is no length limit theoretically. The limit depends on the support of the operating system.

Therefore, when a GET request is submitted, data transmission is limited by the URL length.

Post: theoretically, data is not limited because the value is not transmitted through a URL. However, the actual size of the data submitted by post is limited on each Web server. Apache and IIS6 have their own configurations.

(3) Security:

. Post is more secure than get. Note: The security mentioned here is not the same as the "Security" mentioned in get. The above "security" only means not to modify data, and the meaning of security is the meaning of real security, for example: submit data through get, the username and password will appear in the URL in plain text, because (1) the logon page may be cached by the browser, (2) others can view the historical records of the browser, then others can get your account and password. In addition, using get to submit data may also cause cross-site request forgery attacks.

(4) http get, post, and soap protocols all run on HTTP.
1) Get: The request parameter is appended to the URL as a sequence (query string) of a key/value pair.
The length of the query string is limited by the web browser and the Web server (for example, ie supports a maximum of 2048 characters). It is not suitable for transmitting large datasets and is not safe.
2) post: Request Parameters are transmitted in a different part of the HTTP header (Named Entity body). This part is used to transmit form information. Therefore, you must set Content-Type: application/X-WWW-form-urlencoded. Post is designed to support user fields on web forms. Its parameters are also transmitted as key/value pairs.
However, it does not support complex data types, because post does not define the semantics and rules of the transmitted data structure.
3) soap: a special version of http post, which follows a special XML Message format.
Content-Type is set to text/XML. Any data can be XML-based.

 

3. Http response
1. Http response format:

<Status line>
<Headers>
<Blank line>
[<Response-body>]

The only real difference in the response is that the request information is replaced by the State Information in the first line. Status line describes the requested resources by providing a status code.

HTTP Response instance:

HTTP/1.1 200 OK
Date: sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html; charset = ISO-8859-1
Content-Length: 122
<HTML>
<Head>
<Title> wrox homepage </title>
</Head>
<Body>
<! -- Body goes here -->
</Body>
</Html>
2. The most common status codes are:

◆ 200 (OK): The resource is found and everything is normal.
◆ 304 (not modified): The resource has not been modified since the last request. This is usually used for browser caching.
◆ 401 (unauthorized): the client has no permission to access this resource. This usually requires the user to enter the user name and password in the browser to log on to the server.
◆ 403 (Forbidden): the client is not authorized. This is usually because an incorrect user name or password is entered after 401.
◆ 404 (not found): the requested resource does not exist at the specified position.

 

Example 4:

Example:

HTTP GET 

Send

GET/demowebservices2.8/service. asmx/cancelorder? Userid = string & Pwd = string & orderconfirmation = string HTTP/1.1
HOST: api.efxnow.com

Reply

HTTP/1.1 200 OK
Content-Type: text/XML; charset = UTF-8
Content-Length: Length

<? XML version = "1.0" encoding = "UTF-8"?>
<Objplaceorderresponse xmlns = "https://api.efxnow.com/webservices2.3">
<Success> Boolean </success>
<Errordescription> string </errordescription>
<Errornumber> int </errornumber>
<Customerorderreference> long </customerorderreference>
<Orderconfirmation> string </orderconfirmation>
<Customerdealref> string </customerdealref>
</Objplaceorderresponse>



HTTP POST 

Send

Post/demowebservices2.8/service. asmx/cancelorder HTTP/1.1
HOST: api.efxnow.com
Content-Type: Application/X-WWW-form-urlencoded
Content-Length: Length

Userid = string & Pwd = string & orderconfirmation = string

Reply

HTTP/1.1 200 OK
Content-Type: text/XML; charset = UTF-8
Content-Length: Length

<? XML version = "1.0" encoding = "UTF-8"?>
<Objplaceorderresponse xmlns = "https://api.efxnow.com/webservices2.3">
<Success> Boolean </success>
<Errordescription> string </errordescription>
<Errornumber> int </errornumber>
<Customerorderreference> long </customerorderreference>
<Orderconfirmation> string </orderconfirmation>
<Customerdealref> string </customerdealref>
</Objplaceorderresponse>



HTTP 1.2 

Send

Post/demowebservices2.8/service. asmx HTTP/1.1
HOST: api.efxnow.com
Content-Type: Application/soap + XML; charset = UTF-8
Content-Length: Length

<? XML version = "1.0" encoding = "UTF-8"?>
<Soap12: envelope xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns: XSD = "http://www.w3.org/2001/XMLSchema" xmlns: soap12 = "http://www.w3.org/2003/05/soap-envelope">
<Soap12: Body>
<Cancelorder xmlns = "https://api.efxnow.com/webservices2.3">
<Userid> string </userid>
<PWD> string </pwd>
<Orderconfirmation> string </orderconfirmation>
</Cancelorder>
</Soap12: Body>
</Soap12: envelope>

Reply

HTTP/1.1 200 OK
Content-Type: Application/soap + XML; charset = UTF-8
Content-Length: Length

<? XML version = "1.0" encoding = "UTF-8"?>
<Soap12: envelope xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns: XSD = "http://www.w3.org/2001/XMLSchema" xmlns: soap12 = "http://www.w3.org/2003/05/soap-envelope">
<Soap12: Body>
<Cancelorderresponse xmlns = "https://api.efxnow.com/webservices2.3">
<Cancelorderresult>
<Success> Boolean </success>
<Errordescription> string </errordescription>
<Errornumber> int </errornumber>
<Customerorderreference> long </customerorderreference>
<Orderconfirmation> string </orderconfirmation>
<Customerdealref> string </customerdealref>
</Cancelorderresult>
</Cancelorderresponse>
</Soap12: Body>
</Soap12: envelope>

 

 

The early version of HTTP is HTTP/0.9, which is applicable to simple and fast protocols for various data information, but it is far from meeting the needs of increasingly developed applications. However, HTTP/0.9 is a typical stateless HTTP protocol: each transaction is processed independently. When a transaction starts, it establishes a connection between the customer and the server, the connection is released when the transaction ends. HTTP/0.9 contains the message structure of simple-request & simple-responsed. However, the client cannot use content negotiation, so the server cannot return the media type of the entity.
In 1982, Tim Berners-Lee proposed HTTP/1.0. In the future, HTTP/1.0 becomes the most important transaction-oriented application layer protocol. This Protocol establishes and removes a connection for each request/response. It is simple and easy to manage, so it meets everyone's needs and has been widely used. The disadvantage is that the following problems still occur: slow response to user requests, severe network congestion, and security.
HTTP/1997, a commonly used protocol established in 1.1, implements the stream mode in the persistent connection operation mechanism, that is, when the client needs to send multiple requests to the same server, in fact, most web pages are composed of multiple parts (for example, multiple images). The Streamline method is used to speed up the process. The Streamline mechanism is to send multiple requests continuously and wait until these requests are sent, wait for the response. In this way, the waiting time for the response of individual requests is greatly reduced, so that we can view the response more quickly.
In addition, the HTTP/1.1 Server Processes requests in the order they are received, ensuring the correctness of transmission. Of course, when a connection is interrupted, the server automatically retransmits the request to ensure data integrity.
HTTP/1.1 also provides identity authentication, status management, cache caching, and other mechanisms. Here, I would like to mention the improvement of the cache mechanism in HTTP/1.1 on the shortcomings of HTTP/1.0. It is strictly and comprehensive, which can reduce the time delay and bandwidth. HTTP/1.1 adopts the content negotiation mechanism and selects the most appropriate content representation form.
Currently, the virtual host technology that is useful in many places can also be implemented in HTTP/1.1. The so-called virtual host technology means that the same host address actually corresponds to multiple hosts. In general, when you apply for two Homepages on one website at the same time, you can use the protocol analyzer to find that the two homepages correspond to the same IP address. In this way, using multiple identical machines to form a WWW server can increase the processing throughput.
The traditional solution is to transform the domain name server so that it can interpret the same domain name as different IP addresses based on certain algorithms. The disadvantage of corresponding to each machine of the virtual host is that each machine occupies a completely independent IP address, which is in conflict with the lack of IP addresses.
The solution provided by HTTP/1.1 includes the function of specifying different hosts in the HTTP protocol itself, so that multiple hosts can share one IP address, which improves performance and facilitates management.
Because HTTP/1.1 is a standard protocol for the Internet, the relevant syntax is described in detail here.
First, the HTTP/1.1 format can be written as follows:
The request method is to request a certain webpage program or a specific URL. The following options are available:
Get: Request the specified page information and returns the Object Body.
Head: only request the first part of the page.
Post: The request Server accepts the specified document as a new subordinate object to the identified Uri.
Put: Replace the specified document content with the data transmitted from the client to the server.
Delete: Requests the server to delete the specified page.
Options: allows the client to view the server performance.
Trace: The content returned by the request server in the response body.
Patch: an object contains a table that describes the differences between the table and the original content represented by the URI.
Move: Requests the server to move the specified page to another network address.
Copy: Requests the server to copy the specified page to another network address.
Link: Requests the server to establish a link.
Unlink: disconnected.
Wrapped: allows the client to send encapsulated requests.
Extension-mothed: You can add another method without modifying the protocol.
For example:
GET/index.html HTTP/1.1
Accept: text/plain/* plain ASCII text file */
Accept: text/html/* HTML text file */
User-Agent: Mozilla/4.5 (winnt)
The browser uses the get method to request the document/index.html. The browser can only receive plain ASCII text files and HTML text files. The engine used is Mozilla/4.5 (Netscape ).

When the server responds, the status line information is the HTTP Version Number, status code, and a brief description of the status code. Five status codes are listed in detail:
① Client Error
100 continue
101 Exchange Protocol
② Success
200 OK
201 created
202 receiving
203 non-authentication information
204 NO content
205 reset content
Part 1
③ Redirection
300 multi-Choice
301 permanent transfer
302 temporary transfer
303 see other
304 unmodified (not modified)
305 use proxy
④ Client errors
400 bad request)
401 unauthenticated
402 payment required
403 Forbidden)
404 not found)
405 method not allowed
406 not accepted
407 proxy authentication required
408 request timeout
409 conflict
410 failed
411 length required
412 condition failed
413 the Request Entity is too large
414 the request URI is too long
415 media types not supported
⑤ Server Error
500 Internal Server Error
501 not implemented (not implemented)
502 gateway failure
504 gateway timeout
505 HTTP Version Not Supported
For example, in Telnet... Use telnet to log on to port 80. If the same method is used in HTTP/1.1, no information is displayed)
Telnet www.fudan.edu.cn 80
Headers/HTTP/1.1
HOST: www.fudan.edu.cn/* content entered in this behavior */
HTTP/1.1 501 method not implemented
Date: Web, 01 Nov 2000 07:12:29 GMT/* Current date/time */
Server: Apache/1.3.12 (UNIX)/* Web server information */
Allow: Get, Head, option, trace/* supported method types */
Connection: Close
Connect-type: text/html; charset = iso-8859-1/* connected media type */

<! Doctype HTML publig "-// IETF // dtd html 2.0 // en">
<HTML> <Title> 501 Method
Not implemented </title>
</Head> <body>
<H1> method not implemented Head to/inde
X.html not supported. <p>
Invalid method in request head/HTP/1.1 <p>
<HR>
<Address>
Apache/1.3.12 server at www.fudan.edu.cn port 80 </address>
</Body> The content of the object header can also be:
Last modified: The latest modification time of the Request Document.
Expires: The expiration time of the Request Document.
Connect-length: the length of the document data.
WWW-authenricate: indicates the authentication information required by the client.
Connect-encoding: whether compression technology is used.
Transfer-encoding: Specifies the encoding conversion type.

With the development of the Internet, the next generation of HTTP protocol HTTP-ng has been brewing, it will provide better security, faster speed, its improvement points are: strong modularity, high network efficiency, better security, and simpler structure.

Http get post