Http基础三 Post Get

不清楚CSRF的，可以先看看Http基础一 cookie session token和Http基础二 Web安全简介 SQL注入 XSS CSRF(token)。

一、post 相比get 有很多优点，为什么现在的HTTP通信中大多数请求还是使用get？

1.POST 是否比 GET 安全

是的， POST要比GET安全一点点，注意，是一点点。。。说这两者都是明文传送当然是没有错的了，但是这里有一个细节，就是GET的URL会被放在浏览器历史和WEB 服务器日志里面。POST 发完基本就木有了。。所以如果你把关键数据放在GET里面，被人偷窥了浏览器，或者WEB服务器被入侵日志被人倒去了，基本泄露可能性100%。而POST来说，日志没有记录，只要数据库服务器不被入侵，基本还是安全的。当然如果被抓了包，这一切都没有什么卵用，所以，HTTPS该用还是得用。

2.GET 相对 POST 的优势是什么

最大的优势是， GET 的URL可以人肉手输啊。。。你在地址栏打个POST给我看看。本质上面， GET 的所有信息都在URL， 所以很方便的记录下来重复使用。

所以如果你希望

• 请求中的URL可以被手动输入
• 请求中的URL可以被存在书签里，或者历史里，或者快速拨号里面，或者分享给别人。－ 请求中的URL是可以被搜索引擎收录的。
• 带云压缩的浏览器，比如Opera mini/Turbo 2, 只有GET才能在服务器端被预取的。
• 请求中的URL可以被缓存。请使用GET.

大家有没有注意到，其实这里面很多方面的要求是和网站的运营相关的，而不是技术相关的。任何的技术行为中，其实多多少少都能看到商业的影子。

反之，就用POST. 特别是有一些东西你是不想让人家可以在浏览器地址栏里面可以输入的。比如，如果你设计一个blog系统, 设计这样一个URL来删掉所有帖子。http://myblog.com/?action=delete_all。我只能说很快你就知道什么叫不作死就不会死这个道理了，搜索引擎的爬虫分分钟教你做人。

另外一个准则是，可以重复的交互，比如取个数据，跳个页面， 用GET.不可以重复的操作， 比如创建一个条目/修改一条记录， 用POST, 因为POST不能被缓存，所以浏览器不会多次提交。WEB API 的设计相对于网页来说更加复杂，同时也有GET/POST的问题，目前主流接受的方法是RESTful

3. 这里另一个答主提到了CDN缓存

get表达的是一种幂等的，只读的，纯粹的操作，即它除了返回结果不应该会产生其它副作用（如写数据库），因此绝大部分get请求（通常超过90%）都直接被CDN缓存了，这能大大减少web服务器的负担。

而post所表达的语义是非幂等的，有副作用的操作，所以必须交由web服务器处理。把所有get请求换成post，意味着主干网络上的所有CDN都废掉了，web服务器要处理的请求数量将成百上千倍地增加，显然这不是一个聪明的做法！

二、get和post区别？

1.通常的理解

w3schools关于这个问题的解答：HTTP 方法：GET 对比 POST 列出了一般的理解，比如：

• GET后退按钮/刷新无害，POST数据会被重新提交（浏览器应该告知用户数据会被重新提交）。
• GET书签可收藏，POST为书签不可收藏。
• GET能被缓存，POST不能缓存 。
• GET编码类型application/x-www-form-url，POST编码类型encodedapplication/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
• GET历史参数保留在浏览器历史中。POST参数不会保存在浏览器历史中。
• GET对数据长度有限制，当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。POST无限制。
• GET只允许 ASCII 字符。POST没有限制。也允许二进制数据。
• 与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。在发送密码或其他敏感信息时绝不要使用 GET ！POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。
• GET的数据在 URL 中对所有人都是可见的。POST的数据不会显示在 URL 中。

2.关于语义上的差别

一种语言是合法句子的集合。什么样的句子是合法的呢？可以从两方面来判断：语法和语义。语法是和文法结构有关，然而语义是和按照这个结构所组合的单词符号的意义有关。合理的语法结构并不表明语义是合法的。例如我们常说：我上大学，这个句子是符合语法规则的，也符合语义规则。但是大学上我，虽然符合语法规则，但没有什么意义，所以说是不符合语义的。

GET的语义是请求获取指定的资源。GET方法是安全、幂等、可缓存的（除非有 Cache-ControlHeader的约束）,GET方法的报文主体没有任何语义。

POST的语义是根据请求负荷（报文主体）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST不安全，不幂等，（大部分实现）不可缓存。为了针对其不可缓存性，有一系列的方法来进行优化，以后有机会再研究（FLAG已经立起）。

还是举一个通俗栗子吧，在微博这个场景里，GET的语义会被用在「看看我的Timeline上最新的20条微博」这样的场景，而POST的语义会被用在「发微博、评论、点赞」这样的场景中。

另外，关于HTTP中的GET和POST，浏览器在喊冤也提到这个观点。

三、都2019年了，还问GET和POST的区别

1.GET 和 POST 报文上的区别

先下结论，GET 和 POST 方法没有实质区别，只是报文格式不同。

GET 和 POST 只是 HTTP 协议中两种请求方式，而 HTTP 协议是基于 TCP/IP 的应用层协议，无论 GET 还是 POST，用的都是同一个传输层协议，所以在传输上，没有区别。

报文格式上，不带参数时，最大区别就是第一行方法名不同

POST方法请求报文第一行是这样的 POST /uri HTTP/1.1 \r\n

GET方法请求报文第一行是这样的 GET /uri HTTP/1.1 \r\n

是的，不带参数时他们的区别就仅仅是报文的前几个字符不同而已

带参数时报文的区别呢？ 在约定中，GET 方法的参数应该放在 url 中，POST 方法参数应该放在 body 中

举个例子，如果参数是 name=qiming.c, age=22。

GET 方法简约版报文是这样的

 

GET /index.php?name=qiming.c&age=22 HTTP/1.1
Host: localhost

POST 方法简约版报文是这样的

 

POST /index.php HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
​
name=qiming.c&age=22

现在我们知道了两种方法本质上是 TCP 连接，没有差别，也就是说，如果我不按规范来也是可以的。我们可以在 URL 上写参数，然后方法使用 POST；也可以在 Body 写参数，然后方法使用 GET。当然，这需要服务端支持。

2.GET 方法参数写法是固定的吗？

在约定中，我们的参数是写在 ? 后面，用 & 分割。

我们知道，解析报文的过程是通过获取 TCP 数据，用正则等工具从数据中获取 Header 和 Body，从而提取参数。

也就是说，我们可以自己约定参数的写法，只要服务端能够解释出来就行，一种比较流行的写法是 http://www.example.com/user/name/chengqm/age/22。

3.POST 方法比 GET 方法安全？

按照网上大部分文章的解释，POST 比 GET 安全，因为数据在地址栏上不可见。

然而，从传输的角度来说，他们都是不安全的，因为 HTTP 在网络上是明文传输的，只要在网络节点上捉包，就能完整地获取数据报文。

要想安全传输，就只有加密，也就是 HTTPS。

4.GET 方法的长度限制是怎么回事？

在网上看到很多关于两者区别的文章都有这一条，提到浏览器地址栏输入的参数是有限的。

首先说明一点，HTTP 协议没有 Body 和 URL 的长度限制，对 URL 限制的大多是浏览器和服务器的原因。

浏览器原因就不说了，服务器是因为处理长 URL 要消耗比较多的资源，为了性能和安全（防止恶意构造长 URL 来攻击）考虑，会给 URL 长度加限制。

5.POST 方法会产生两个TCP数据包？

有些文章中提到，post 会将 header 和 body 分开发送，先发送 header，服务端返回 100 状态码再发送 body。

HTTP 协议中没有明确说明 POST 会产生两个 TCP 数据包，而且实际测试(Chrome)发现，header 和 body 不会分开发送。

所以，header 和 body 分开发送是部分浏览器或框架的请求方法，不属于 post 必然行为。