IOS development-post/get

IOS development-post/get

I. Differences

On the surface, the difference between get and post is that get gets data and post sends data. This is a misunderstanding. In fact, both of them are acceptable, and parameters can be included in the request sent to the server by IOS.

So how did these misunderstandings occur? Let's take a look at the explanation of http.

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 interaction with the server. There are four basic methods: GET, POST, PUT, and DELETE.
The full name of a URL is a resource descriptor. We can think that a URL address 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, we 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, it is also the intent of the Protocol designer. Other differences are the differences in specific forms ).

Let's take a closer look at the differences between them:

1. GET uses URL or Cookie to pass parameters. POST puts the data in the BODY.

2. GET URLs have length restrictions, so the POST data can be very large.

3. POST is safer than GET because the data is invisible in the address bar.

These are also a bit of misunderstandings, just like a slow synchronization request?

GET and POST are irrelevant to how data is transmitted?



GET and POST are defined by the HTTP protocol. In HTTP, Method and Data (URL, Body, Header) are two orthogonal concepts. That is to say, there is no relationship between which Method is used and how Data is transmitted at the application layer.

HTTP is not required. If the Method is POST data, it must be placed in the BODY. There is no requirement either. If the Method is GET, the data (parameter) must be placed in the URL rather than in the BODY.

So where did the widely circulated online saying come from? I found a similar description in the HTML standard. This is consistent with the statement circulating on the Internet. However, this is only an HTML standard convention for HTTP protocol usage. How is the difference between GET and POST?

In addition, modern Web servers support requests such as GET containing the BODY. Although such requests cannot be sent from the browser, the current Web Server is not only used by the browser, it is completely beyond the scope of the HTML Server.

Does the HTTP protocol have no limit on the length of GET and POST?

The HTTP Protocol clearly states that neither the HTTP header nor the Body has a length requirement. There are two reasons for the restriction on the URL Length:

1. browser. It is said that early browsers will limit the URL length. It is said that IE will limit the URL length to 2048 characters (widely spread, and many colleagues agree ). But I tried it myself. I constructed a 90 K URL and accessed live.com through IE9, which is normal. Online content, even on Wikipedia, cannot be sent.

2. server. The URL is too long to process the server. The original session does not have much data. Now, if someone maliciously constructs several M-sized URLs and keeps accessing your server. The maximum concurrency of the server is obviously decreased. Another attack method is to tell the server that Content-Length is a large number, and then send only a little data to the server. Hey hey, you can wait for the server. Even if you have time-out settings, this deliberate time-out for the second access can make the server fail to eat. In view of this, most servers impose restrictions on the URL Length for security and stability considerations. However, this restriction applies to all HTTP requests and has nothing to do with GET and POST.

This seems like a bit interesting.

3. Security and insecurity.

Get:

. The so-called security means that this operation is used to obtain information instead of modifying 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.



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, but here Security means the meaning of true Security. For example, if you submit data through GET, the user name and password will appear in the URL in plain text, because (1) the login page may be cached by the browser, (2) if others view the browser's historical records, they will be able to get your account and password. In addition, using GET to submit data may also cause Cross-site request forgery attacks.

Let's see the difference.

II. Instance

Get is relatively simple. The following is the post code.

// Parameters submitted by post, in the following format: // parameter 1 name = parameter 1 Data & Parameter 2 name = parameter 2 Data & Parameter 3 name = parameter 3 Data &... NSString * post = [NSString stringWithFormat: @ "m = check_user_login_info & f = itemgarden_iphone_app & u =%@ & s =%@", self. us_email, self. us_password]; NSLog (@ "post: % @", post); // convert NSSrring parameters to NSData. NSData must be used for POST submission. NSData * postData = [post dataUsingEncoding: NSUTF8StringEncoding allowLossyConversion: YES]; // calculate the length of the data submitted by POST: NSString * postLength = [NSString stringWithFormat: @ "% d ", [postData length]; NSLog (@ "postLength = % @", postLength); // defines NSMutableURLRequest * request = [[NSMutableURLRequest alloc] init] orautelease]; // set the submission destination url [request setURL: [NSURL URLWithString: kUserLoginCheckUrl]; // Sets POST [request setHTTPMethod: @ "POST"]; // set http-header: Content-Type // set to application/x-www-form-urlencoded, if it is set to another, such as text/html; charset = UTF-8, or text/html, errors will occur. I don't know why. [Request setValue: @ "application/x-www-form-urlencoded" forHTTPHeaderField: @ "Content-Type"]; // set http-header: Content-Length [request setValue: postLength forHTTPHeaderField: @ "Content-Length"]; // set the Content to be submitted by post [request setHTTPBody: postData]; // define NSHTTPURLResponse * urlResponse = nil; NSError * error = [[NSError alloc] init]; // synchronous submission: Submit the POST and wait for the returned value (synchronous). The returned value is of the NSData type. NSData * responseData = [NSURLConnection sendSynchronousRequest: request returningResponse: & urlResponse error: & error]; // convert the NSData type return value to NSString type NSString * result = [[NSString alloc] initWithData: responseData encoding: NSUTF8StringEncoding]; NSLog (@ "user login check result: % @ ", result); if ([@" success "compare: result] = NSOrderedSame) {return YES;} return NO;