(. 1) is safer post (not part of the url, will not be cached, log stored on the server, and a browser to log)
more (2) data transmitted post (get there url length limit)
(3) post can transmit more data types (get only send ASCII characters)
(. 4) post get slower than
(. 5) and to write data to modify the post, get a general search for sorting and filtering operations like (Taobao, Alipay get a search query is submitted), the purpose is to obtain resources, read data
First, why get faster than post
1.post request contains more request header
as post data need to be included in the body of the request, it will be a few more header field data description section (such as: content-type), which in fact, it is minimal.
2. The most important one, post the data before actually receiving the hair will first request confirmation to the server, and then send the data really
process post requests:
(1) browser requests tcp connection (first handshake)
(2 ) promised for tcp connection server (second handshake)
(3) confirmed the browser, and send post request header (third handshake, the packet is relatively small, it will for the first time http data transmission in this case)
( 4) the server returns the response 100 Continue
(5) the browser sends the data
(6) the server returns a 200 OK response to
the process of the get request:
(1) the browser requests connection tcp (first handshake)
(2) connected to the server promise for tcp ( the second handshake)
(3) browser to confirm and send get request headers and data (third handshake, this message is relatively small, it will be the first time http transmit data at this point)
(4) server returns a 200 OK response
is to say, the total consumption is about post visually get 2/3 of this I said rumor, internet users have been tested.
3.get data will be cached, and the post will not be
possible to make a short test, using ajax request using get way static data (such as html pages, pictures), when, if the data transmission is the same twice, the second time after the post time will be consumed every time consumes almost all the time in 10ms or less (chrome testing). After testing, chrome and firefox get detected if the request is a static resource, it will cache, if the data is not cached, but what IE will cache up, of course, no one should use static data post to acquire it, anyway, I have not seen.
4.post can not be pipelined transmission
http authoritative guide had this to say: once a session, you need to establish tcp connection http (mostly tcp, but other security protocols are possible), and then to communicate, if each connection http session only once, and that the proportion of the connection process too! So there is a persistent connection: keep-alive adding connection header value in http / 1.0 +, the value is added in the header portion persistent connection at http / 1.1, of course, not only the difference in the two named, http / 1.1 , the persistent connection is the default, unless added in the connection in close, or persistent connection is not closed, and http / 1.0 + in the contrary, unless the display was added keep-alive in the header connection, otherwise the packet reception connection is disconnected.
Persistent connections appeared enough in http / 1.1, the embodiment there is a conduit communicating called optimized for speed: the need to send all requests to the server into the output queue, after sending out a first request, do not wait until the server response is received, the second request is then immediately sent out, but this way there is a problem: insecurity, if there is a pipe connection 10, after sending out nine, suddenly the server to tell you, the connection is closed, this time even though the client received a reply from the first nine months of the request, will request the contents of these nine empty, that is to say, a futile trip ...... At this point, the client requests that need to be resent 9 . This is okay (such as get, send more than a few times does not matter, the same result each time) to idempotent request, if that is the non-idempotent request post (such as when paid, will suffer more than send a few times) definitely not work.
Therefore, post request by way of the conduit can communicate! Most likely, post requests need to re-establish the connection, this process did not fully optimized with time like that? So, when you can use get a request for communication, do not use post requests, so the user experience will be better, of course, if there are security requirements, then, post will be better. Pipeline transport needs of research in achieving the browser side, looks like the case of default most browsers (except opera) are not pipelined transmission, unless manually open!
Two, get parameter passing the maximum length of misunderstanding
1. summary
(1) http protocol does not specify length limits and get the post
(2) the maximum length is due to get the browser and the web server limits the length of the URL
(3) different browsers and web servers, limiting the maximum length is not the same
(4) to support IE, the maximum length of 2083byte, if supported by Chrome, the maximum length 8182byte
2. misunderstanding
(1) has a first length limit even get, it is to limit the length of the entire URL, rather than the data length of the parameter value, a predetermined number HTTP protocol request never get / post length limit is
(2) a so-called Request length limitation browsers and web servers are determined and set by the various browsers and web servers are not the same setting, depending on the respective predetermined browser manufacturer or may be set according to the processing capability of the web server. IE and Safari browser limitations 2k, Opera restriction 4k, Firefox restrictions 8k (very old version 256byte), if exceeds the maximum length, cut off most of the server directly, some servers will be reported 414 errors.
3. The maximum length of each browser and web server summary
browser
(1) IE: IE browser (Microsoft Internet Explorer) to url length limit is 2083 (2K + 53), exceeds this limit, it is automatically cut off (if form submission the submit button does not work).
(2) firefox: firefox (Firefox) url length limit of 65,536 characters, but in fact valid URL maximum length of less than 100,000 characters.
(3) chrome: chrome (Google) the url length limit over 8182 when the characters return errors listed at the beginning of this article.
(4) Safari: Safari's url length limit of at least 80,000 characters.
(5) Opera: Opera browser url length is limited to 190,000 characters. Still able to edit the normal input character Opera9 190000 address bar.
Server
(1) Apache: Apache can accept url length is limited to 8192 characters
(2) IIS: Microsoft Internet Information Server (IIS) can accept url length is limited to 16,384 characters. This can be achieved through changes