get,post--Brief Introduction

Source: Internet
Author: User
Tags rfc

This article mainly summarizes and grasps the basic differences between get and post.

    1. HTTP
      HTTP, or Hypertext Transfer Protocol, is one of the most common and commonly used protocols in modern networks and is designed to ensure communication between client and server.
      HTTP works by the "request-response" Protocol between the client and the server.
      The client can be a Web browser, and the server side can be some network application on the computer.
      Typically, the browser initiates an HTTP request to the server, and the server returns a response to the browser. The response contains the status information of the request and the content that may be requested.

    2. Request method
      The HTTP method has options,, POST, PUT, DELETE, TRACE, CONNECT,
      Two of the common HTTP requests are: GET and POST.
      Get is the data that is fetched from the server, and the post is the data to be processed to the specified resource

3. Format
Format of Request message:
<request line>
<blank line>
<request-body>

The GET request data is placed in the HTTP request protocol header (headers), which is followed by a URL, in the form of a query string (name/value pair);
The data submitted by the post is placed in the body of the entity (Request-body).

    1. Cache, bookmarks, history, default method
      4.1 Cache: Get will be cached, post cannot.
      4.2 Bookmarks: Get favorites bookmark, post not bookmark
      4.3 History: URL of Get request, parameter will be left in history by browser, post parameter will not.
      4.4 Default Request: When the From is committed, the default is a GET request if you do not specify method.

    2. Response speed
      A GET request can be cached by the client. will be more efficient than post.
      The get response in an AJAX environment is fast, and post needs to send the HTTP header (headers) before sending the data in the main body (request-body) of the delivery text.

    3. Type restrictions
      The value of the 6.1 get limit data set must be an ASCII character;
      The data submitted by get will be appended to the URL, separated from the URL.
      1. With the? To separate URLs and data;
      2. Separate the parameters with &;
      3. If the data is in English or digital, send it as is;
      4. BASE64 encoding If the data is Chinese or other characters
      5.GET Add the data in the form of Variable=value, after the URL;
      such as: http://www.abc.com/?username=yt&id=123

6.2 Post has no restrictions, allowing binary data.
Post is to put the data in the requested data body (Request-body), in accordance with the query string (name/value pairs), the way to pass to the URL;

    1. Size limit
      Data submitted in 7.1.GET can be up to 1024 bytes, post supports large data transfer

7.2HTTP protocol has no limit on the length of Get and post
There is no limit to the length of the URI explicitly in RFC 2616.
However, although the length of the URI is not limited in the RFC, the length of the URL is limited by the major browser manufacturer implementations.
IE's limit on URL length is 2083 bytes (2k+35)

There are two reasons for the limitation of URL length (Security considerations):
Browser: It is said that the early browser will limit the length of the URL. IE will limit the URL length to 2,083 characters, and Chrome crashes.
Server: The URL is long, and the server processing is also a burden.
There is not much data for a session, and now if someone maliciously constructs several m-size URLs,
and keep on accessing your server. The maximum number of concurrent servers will obviously drop.
Another way to attack is: to tell the server content-length is a very large number,
Then only send a bit of data to the server, hey, the server you are foolish to wait to go.
Even if you have a timeout setting, this deliberate secondary access timeout can also make the server suffer.
In view of this, most servers for security, stability considerations, the URL length will be added restrictions.
However, this restriction is for all HTTP requests and is not related to get or post.

    1. In practice,-post is safer than get"."
      The data sent by get is part of the URL,
      Sometimes it responds directly to the browser's address bar,
      Most browsers now remember the URLs you've entered (never use GET when sending passwords or sensitive information!). )。
      Imagine if you've ever filled out a very private form on someone's computer, your record is likely to be seen by people who have no computer knowledge.

But the POST request after the packet was caught is as bare as the GET request, so this is relative.

    1. Semantically-get is more secure than post""
      It is not entirely right to say that POST is safe than GET.
      According to the HTTP specification, post represents a request that may modify resources on the server.
      In terms of semantics (restful view):
      Get is a read operation that gets the resource on the specified URL.
      The important point is that no matter how many times a resource is get, its state will not change,
      In this sense, we say get is safe (not in the sense of cryptography or data protection).
      Because get is secure, the contents returned by get can be cached by the browser and cache server.

The semantics of post is to modify the request of resources on the server, so it is unsafe,
Each time the post is submitted, the code will assume that the operation modifies the state of the resource.
As a result, the browser will jump out of the confirmation box when you press F5, and the cache server will not cache the POST request return content.

get,post--Brief Introduction

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.