search

bibi7 / fe-daily-increase

一个记录开发日常和奇奇怪怪的点的repo
MIT License
5 stars 0 forks source link

get和post？ #53

Open bibi7 opened 4 years ago

bibi7 commented 4 years ago

事实上开发工程师遇到这个问题往往能说点什么出来，比如：

  1. 从传参的角度来说，GET请求的数据会附在URL之后，以?分割URL和传输数据，参数之间以&相连，而post往往把数据放在body之中。

  2. 从安全性的角度来说，post比get更安全。

  3. GET在浏览器回退时是无害的，而POST会再次提交请求。

  4. GET请求在URL中传送的参数是有长度限制的，而POST没有。

  5. 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。

  6. get是幂等的，post是非幂等的

来点不一样的

一个正常的http请求中包含着这么几个部分：

<METHOD> <URL> HTTP/1.1\r\n
<Header1>: <HeaderValue1>\r\n
<Header2>: <HeaderValue2>\r\n
...
<HeaderN>: <HeaderValueN>\r\n
\r\n
<Body Data....>

get不能有body？

放屁，详见

从协议本身来说，RFC并没有如此规定，但是Get 不用body是W3C的标准，所以mdn和rfc在这点上表现不一致也情有可原。

关于安全性

我们常听到GET不如POST安全，因为POST用body传输数据，而GET用url传输，更加容易看到。但是从攻击的角度，无论是GET还是POST都不够安全，因为HTTP本身是明文协议。每个HTTP请求和返回的每个byte都会在网络上明文传播，不管是url，header还是body。这完全不是一个“是否容易在浏览器地址栏上看到“的问题。

所谓的get参数有长度限制

实际上，GET数据有长度限制“其实是指”URL的长度限制“。URL不存在参数上限的问题，HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。且不同的浏览器这一块的限制还不一样，一般说的2048指的是ie8。

post其实会偷偷发两次请求？

这个其实还是对的，客户端可以利用HTTP的Continued协议来这样做：客户端总是先发送所有请求头给服务器，让服务器校验。如果通过了，服务器回复“100 - Continue”，客户端再把剩下的数据发给服务器。如果请求被拒了，服务器就回复个400之类的错误，这个交互就终止。 同时，这个情况只有在请求中带了Expect: 100-continue才会生效。

来源

GET 和 POST 到底有什么区别？ 听说『99% 的人都理解错了 HTTP 中 GET 与 POST 的区别』？？

我一直认为这个问题最重要的还是从语义上的区别，用符合规范的方式去实现系统可以减少很多工作量。同时原文这段话我还挺喜欢的：

我们通常在讨论 GET vs POST 的时候，实际上讨论的是 specification，而不是 implementation。什么是 specification？说白了就是相关的 RFC。implementation 则是所有实现了 specification 中描述的代码/库/产品，比如 curl，Python 的 requests 库，或者 Chrome。

POST 请求怎么发送，根本就不是这段 RFC 在讨论的事情。RFC 中只说明了 100 continue 和 Expect header 的联系，比如你想在 GET 请求里带 body，一样可以发送 Expect: 100-continue 并等待 100 continue，这是符合标准的。