GET和POST有什么区别？及为什么网上的多数答案都是错的。

 

  如果有人问你，GET和POST，有什么区别？你会如何回答？

我的经历

 

     前几天有人问我这个问题。我说GET是用于获取数据的，POST，一般用于将数据发给服务器之用。

    这个答案好像并不是他想要的。于是他继续追问有没有别的区别？我说这就是个名字而已，如果服务器支持，他完全可以把GET改个名字叫GET2。他反问道，那就是单纯的名字上的区别喽？我想了想，我觉得如果说再具体的区别，只能去看RFC文档了，还要取决于服务器（指Apache，IIS）的具体实现。但我不得不承认，我的确没有仔细看过HTTP的RFC文档。于是我说，我对HTTP协议不太熟悉。这个问题也就结束了。

最普遍的答案

 

     回来之后寻思了很久，他到底是想问我什么？我一直就觉得GET和POST没有什么除了语义之外的区别，自打我开始学习Web编程开始就是这么理解的。

     可能很多人都已经猜到了，他要的答案是：

1. GET使用URL或Cookie传参。而POST将数据放在BODY中。

2. GET的URL会有长度上的限制，则POST的数据则可以非常大。

3. POST比GET安全，因为数据在地址栏上不可见。

     但是很不幸，这些区别全是错误的，更不幸的是，这个答案还是Google搜索的头版头条，然而我根本没想着这些是答案，因为在我看来他们都是错的。我来一一解释一下。

GET和POST与数据如何传递没有关系

 

     GET和POST是由HTTP协议定义的。在HTTP协议中，Method和Data（URL， Body， Header）是正交的两个概念，也就是说，使用哪个Method与应用层的数据如何传输是没有相互关系的。

     HTTP没有要求，如果Method是POST数据就要放在BODY中。也没有要求，如果Method是GET，数据（参数）就一定要放在URL中而不能放在BODY中。

     那么，网上流传甚广的这个说法是从何而来的呢？我在HTML标准中，找到了相似的描述。这和网上流传的说法一致。但是这只是HTML标准对HTTP协议的用法的约定。怎么能当成GET和POST的区别呢？

    而且，现代的Web Server都是支持GET中包含BODY这样的请求。虽然这种请求不可能从浏览器发出，但是现在的Web Server又不是只给浏览器用，已经完全地超出了HTML服务器的范畴了。

     知道这个有什么用？我不想解释了，有时候就得自己痛一次才记得住。

HTTP协议对GET和POST都没有对长度的限制

 

     HTTP协议明确地指出了，HTTP头和Body都没有长度的要求。而对于URL长度上的限制，有两方面的原因造成：

     1. 浏览器。据说早期的浏览器会对URL长度做限制。据说IE对URL长度会限制在2048个字符内（流传很广，而且无数同事都表示认同）。但我自己试了一下，我构造了90K的URL通过IE9访问live.com，是正常的。网上的东西，哪怕是Wikipedia上的，也不能信。

     2. 服务器。URL长了，对服务器处理也是一种负担。原本一个会话就没有多少数据，现在如果有人恶意地构造几个几M大小的URL，并不停地访问你的服务器。服务器的最大并发数显然会下降。另一种攻击方式是，把告诉服务器Content-Length是一个很大的数，然后只给服务器发一点儿数据，嘿嘿，服务器你就傻等着去吧。哪怕你有超时设置，这种故意的次次访问超时也能让服务器吃不了兜着走。有鉴于此，多数服务器出于安全啦、稳定啦方面的考虑，会给URL长度加限制。但是这个限制是针对所有HTTP请求的，与GET、POST没有关系。

安全不安全和GET、POST没有关系

 

     我觉得这真是中国特色。我讲个小段子，大家应该可以体会出这个说法多么的可笑。

      觉得POST数据比GET数据安全的人会说

    “防君子不防小人；中国小白多，能防小白用户就行了。”

    “哼，”我不以为然，“那你怎么不说，URL参数都Encode过了，或是Base64一下，小白也看不懂啊。”

     那人反驳道，“Encode太简单了，聪明点儿的小白很容易就可以Decode并修改掉。”

     我笑道，“五十步笑百步耳，再聪明点儿的小白还会截包并重发呢，Opera就有这功能。”

     那人阴险地祭出神器——最终解释权，说，“这个不算小白。”

     我日啊。

最后一点儿感想

 

     我之前一直做Windows桌面应用，对Web开发无甚了解，直到一年多前转做服务器端开发，才开始接触到HTTP。（注意，我说的是HTTP，不是HTML。服务器开放接口是基于REST理念设计的，使用的协议是HTTP，但是传输的内容不是HTML。这不是Web Server，而是一个Web Service）

     所以我对于GET和POST的理解，是纯粹地来源于HTTP协议。他们只有一点根本区别，简单点儿说，一个用于获取数据，一个用于修改数据。具体的请参考RFC文档。

     如果一个人一开始就做Web开发，很可能把HTML对HTTP协议的使用方式，当成HTTP协议的唯一的合理使用方式。从而犯了以偏概全的错误。

     可能有人会觉得我钻牛角尖。我只是不喜欢模棱两可，不喜欢边界不清、概念不明，不喜欢“拿来主义”，也不喜欢被其它喜欢钻牛角尖的人奚落得无地自容。

     “知之为知之，不知为不知，是知也。”

评论

19 楼 tlde_ti 2012-07-25  

renzhen 写道

POST自然比GET安全，POST可以防止XSS攻击，很多应用就是将POST和GET混用了，导致XSS流行

请问post是如何防止xss攻击的？！

18 楼 renzhen 2012-07-25  

POST自然比GET安全，POST可以防止XSS攻击，很多应用就是将POST和GET混用了，导致XSS流行

17 楼 osprey 2012-07-23  

post和get在传输数据方面可以说是差不多的
其区别就在 原语 post 和get的区别.
get默认是获取页面 ,post默认是提交数据
在实际使用中,造成一个在web的约定惯例是 同样url(含?后的参数)的get请求(如果在http头部设定的有效时间范围内),在浏览器,正向代理服务器,反向代理服务器等等地方,都可以进行缓存返回,而无须到真正的web应用服务上处理这个请求.
而post可以说是强制缓存无效,必须到达真正的web应用服务器上处理这个请求返回(不要拿某急速浏览器举反例,它是为了所谓速度无视这些约定的惯例的)
所以,一般比较好的web应用,是用get来取一些静态页面或者可以在一段时间内结果是不变的,而post请求都是修改数据,要求返回的是立即更新的结果.
这些在rfc上是无法看到的,因为这是根据规范引申出来的惯例.
当然上面只是引申出来的一部分惯例.这也是在所有web服务器(apache,nigix,iis)的书册里都会有解释的.

16 楼 zhang8h 2012-07-23  

[img][/img][url][/url][flash=200,200][/flash]

引用

[i][/i][b][/b][u][/u]

15 楼 tlde_ti 2012-07-23  

另外就实际上的安全防护来说，
get 和 post 是一样的，都不安全。

14 楼 tlde_ti 2012-07-23  

首先，http的确是没规定Get“必须”是用在url上的，不过现在传统的做法是默认为get方法为url,你当然可以get with body,但是这样与传统做法的交互上就必须多考虑一些东西，不推荐。如果有确实的需要才这样做。
所以有了Get用url传输的常态假设1

假设1下其次,http也的确没有限制Get长度，但浏览器和服务器都有限制"url"长度，你那个2048长度的限制出处“可能”是这个2083 的限制，http://support.microsoft.com/kb/208427，你觉得微软还能自己打自己脸？只是下面标注了，这个限制只对ie4-ie8有效.
更何况http 1.1虽然没有限制"url"的长度，但http也做了这样的警告

引用

Servers should be cautious about depending on URI (which includes URLs) lengths above 255 bytes, because some older client or proxy implementations may not properly support these lengths

。

所以由
1.默认情况下get用url传输（历史，现实原因）
2.url长度不适宜太长
可以得出结论
大部分情况下get“现在”还不适宜于传输太长的数据。

最后。post比get安全这个的确是神论了。post和get本身并没有多少安全防护的意义。只是在语义上有某种安全与不安全的意义，get语义一直被定义为安全方法，因为其不修改服务器上的数据，不进行危险的操作。而post才是危险方法，因为其操作危险，服务器要添加许多验证来保证其安全，客户端也可能加上https这种东西来保护数据。

正因为post本身语义上是危险的，所以额外给其添加了许多安全防护。而那些防护其实是跟post本身无关的。正因为get语义是相对安全的，才可以在地址栏上显示，方便使用和阅读。

13 楼 archy123 2012-07-23  

方向别搞错了。。。为解决问题而讨论。URL长度限制我真遇到过一回，IE8环境，当时将超过4000个权限ID（相当于4000个整数）放到URL后，GET方式访问，发现IE8报错了。当时还以为是JS报错，结果证明是IE不支持那么长的URL，印象中那个临界报错的长度比2048要大

只是不满他说啥网上的东西不可信。

12 楼 liguocai2009 2012-07-23  

archy123 写道

archy123 写道

1. 浏览器。据说早期的浏览器会对URL长度做限制。据说IE对URL长度会限制在2048个字符内（流传很广，而且无数同事都表示认同）。但我自己试了一下，我构造了90K的URL通过IE9访问live.com，是正常的。网上的东西，哪怕是Wikipedia上的，也不能信。

明明都说了早期浏览器，你丫的用IE9测试去。IE9是早期浏览器？我特么笑死了。
还得出结论。网上的东西，哪怕是Wikipedia上的，也不能信。那你以后别google，百度了。反正网上的东西都不可信。

方向别搞错了。。。为解决问题而讨论。URL长度限制我真遇到过一回，IE8环境，当时将超过4000个权限ID（相当于4000个整数）放到URL后，GET方式访问，发现IE8报错了。当时还以为是JS报错，结果证明是IE不支持那么长的URL，印象中那个临界报错的长度比2048要大

11 楼 archy123 2012-07-23  

archy123 写道

1. 浏览器。据说早期的浏览器会对URL长度做限制。据说IE对URL长度会限制在2048个字符内（流传很广，而且无数同事都表示认同）。但我自己试了一下，我构造了90K的URL通过IE9访问live.com，是正常的。网上的东西，哪怕是Wikipedia上的，也不能信。

明明都说了早期浏览器，你丫的用IE9测试去。IE9是早期浏览器？我特么笑死了。
还得出结论。网上的东西，哪怕是Wikipedia上的，也不能信。那你以后别google，百度了。反正网上的东西都不可信。

10 楼 archy123 2012-07-23  

1. 浏览器。据说早期的浏览器会对URL长度做限制。据说IE对URL长度会限制在2048个字符内（流传很广，而且无数同事都表示认同）。但我自己试了一下，我构造了90K的URL通过IE9访问live.com，是正常的。网上的东西，哪怕是Wikipedia上的，也不能信。

明明都说了早期浏览器，你丫的用IE9测试去。IE9是早期浏览器？我特么笑死了。
还得出结论。网上的东西，哪怕是Wikipedia上的，也不能信。那你以后别google，百度了。反正网上的东西都不可信。

9 楼 selvemen 2012-07-23  

liguocai2009 写道

引用

其实基于HTTP和基本TCP的网络程序没有任何区别，如果人的数据是通过你自已程序提交给HTTP服务器的好办了，MD5校验合可以吧，那基于浏览器提交的不也一样可以么，用javaScript在提交前进行MD5，在服务端进行和校验不行么

看来我的问题描述的不够清楚

a GET http://xxxx.com/query?name=liguocai2009
b POST http://xxxx.com/query
  header-key:header-value
  .....

  name=liguocai2009

这两种方式的请求，实现同样的功能。
在浏览器端，通过js控制了用户的输入，他只能查询liguocai2009的数据。如果他通过一些伎俩，把get url改了，或者截取并修改了POST的数据，改成name=admin，那么如果中间层不对用户做单独的数据权限校验的话，就会返回关于管理员的信息。类似的例子就像之前网上流传过的网上订票，牛人通过FIREBUG修改了页面，本来一次只能订一张的，改成了一次订两张。甚至更强一点，自己写客户端发HTTP请求到服务器。

这种类型的安全问题怎么解决。。

https用密钥加密 是不是可以解决

8 楼 liguocai2009 2012-07-23  

引用

其实基于HTTP和基本TCP的网络程序没有任何区别，如果人的数据是通过你自已程序提交给HTTP服务器的好办了，MD5校验合可以吧，那基于浏览器提交的不也一样可以么，用javaScript在提交前进行MD5，在服务端进行和校验不行么

看来我的问题描述的不够清楚

a GET http://xxxx.com/query?name=liguocai2009
b POST http://xxxx.com/query
  header-key:header-value
  .....

  name=liguocai2009

这两种方式的请求，实现同样的功能。
在浏览器端，通过js控制了用户的输入，他只能查询liguocai2009的数据。如果他通过一些伎俩，把get url改了，或者截取并修改了POST的数据，改成name=admin，那么如果中间层不对用户做单独的数据权限校验的话，就会返回关于管理员的信息。类似的例子就像之前网上流传过的网上订票，牛人通过FIREBUG修改了页面，本来一次只能订一张的，改成了一次订两张。甚至更强一点，自己写客户端发HTTP请求到服务器。

这种类型的安全问题怎么解决。。

7 楼 daochuliudeyu 2012-07-23  

冲楼主这股钻劲也给个支持。。。

6 楼 ljl_ss 2012-07-23  

liguocai2009 写道

引用

     我觉得这真是中国特色。我讲个小段子，大家应该可以体会出这个说法多么的可笑。

      觉得POST数据比GET数据安全的人会说

    “防君子不防小人；中国小白多，能防小白用户就行了。”

    “哼，”我不以为然，“那你怎么不说，URL参数都Encode过了，或是Base64一下，小白也看不懂啊。”

     那人反驳道，“Encode太简单了，聪明点儿的小白很容易就可以Decode并修改掉。”

     我笑道，“五十步笑百步耳，再聪明点儿的小白还会截包并重发呢，Opera就有这功能。”

     那人阴险地祭出神器——最终解释权，说，“这个不算小白。”

     我日啊。

刚好我也是在处理公司的安全性问题。

我笑道，“五十步笑百步耳，再聪明点儿的小白还会截包并重发呢，Opera就有这功能。”我们的应用是IE only其他浏览器根本用不了，但是理论上存在一些工具，可以截取请求并修改并且重新发送。目前我也找不到什么好的方法，来确保客户端过来的请求是合法，而不是非法。

既然楼主认为POST也一样会被容修改，有什么好的办法确保客户端过来的数据是合法的呢？
(除了https),或者存在什么方法，让中间层能够校验客户端请求是否合法？

liguocai2009 写道

引用

     我觉得这真是中国特色。我讲个小段子，大家应该可以体会出这个说法多么的可笑。

      觉得POST数据比GET数据安全的人会说

    “防君子不防小人；中国小白多，能防小白用户就行了。”

    “哼，”我不以为然，“那你怎么不说，URL参数都Encode过了，或是Base64一下，小白也看不懂啊。”

     那人反驳道，“Encode太简单了，聪明点儿的小白很容易就可以Decode并修改掉。”

     我笑道，“五十步笑百步耳，再聪明点儿的小白还会截包并重发呢，Opera就有这功能。”

     那人阴险地祭出神器——最终解释权，说，“这个不算小白。”

     我日啊。

刚好我也是在处理公司的安全性问题。

我笑道，“五十步笑百步耳，再聪明点儿的小白还会截包并重发呢，Opera就有这功能。”我们的应用是IE only其他浏览器根本用不了，但是理论上存在一些工具，可以截取请求并修改并且重新发送。目前我也找不到什么好的方法，来确保客户端过来的请求是合法，而不是非法。

既然楼主认为POST也一样会被容修改，有什么好的办法确保客户端过来的数据是合法的呢？
(除了https),或者存在什么方法，让中间层能够校验客户端请求是否合法？

其实基于HTTP和基本TCP的网络程序没有任何区别，如果人的数据是通过你自已程序提交给HTTP服务器的好办了，MD5校验合可以吧，那基于浏览器提交的不也一样可以么，用javaScript在提交前进行MD5，在服务端进行和校验不行么

5 楼 liguocai2009 2012-07-23  

引用

     我觉得这真是中国特色。我讲个小段子，大家应该可以体会出这个说法多么的可笑。

      觉得POST数据比GET数据安全的人会说

    “防君子不防小人；中国小白多，能防小白用户就行了。”

    “哼，”我不以为然，“那你怎么不说，URL参数都Encode过了，或是Base64一下，小白也看不懂啊。”

     那人反驳道，“Encode太简单了，聪明点儿的小白很容易就可以Decode并修改掉。”

     我笑道，“五十步笑百步耳，再聪明点儿的小白还会截包并重发呢，Opera就有这功能。”

     那人阴险地祭出神器——最终解释权，说，“这个不算小白。”

     我日啊。

刚好我也是在处理公司的安全性问题。

我笑道，“五十步笑百步耳，再聪明点儿的小白还会截包并重发呢，Opera就有这功能。”我们的应用是IE only其他浏览器根本用不了，但是理论上存在一些工具，可以截取请求并修改并且重新发送。目前我也找不到什么好的方法，来确保客户端过来的请求是合法，而不是非法。

既然楼主认为POST也一样会被容修改，有什么好的办法确保客户端过来的数据是合法的呢？
(除了https),或者存在什么方法，让中间层能够校验客户端请求是否合法？

4 楼 liguocai2009 2012-07-23  

引用

     我觉得这真是中国特色。我讲个小段子，大家应该可以体会出这个说法多么的可笑。

      觉得POST数据比GET数据安全的人会说

    “防君子不防小人；中国小白多，能防小白用户就行了。”

    “哼，”我不以为然，“那你怎么不说，URL参数都Encode过了，或是Base64一下，小白也看不懂啊。”

     那人反驳道，“Encode太简单了，聪明点儿的小白很容易就可以Decode并修改掉。”

     我笑道，“五十步笑百步耳，再聪明点儿的小白还会截包并重发呢，Opera就有这功能。”

     那人阴险地祭出神器——最终解释权，说，“这个不算小白。”

     我日啊。

刚好我也是在处理公司的安全性问题。

我笑道，“五十步笑百步耳，再聪明点儿的小白还会截包并重发呢，Opera就有这功能。”我们的应用是IE only其他浏览器根本用不了，但是理论上存在一些工具，可以截取请求并修改并且重新发送。目前我也找不到什么好的方法，来确保客户端过来的请求是合法，而不是非法。

既然楼主认为POST

3 楼 ljl_ss 2012-07-23  

写错了  HTML是静态语言

2 楼 ljl_ss 2012-07-23  

HTML是种浏览器支持的动态脚本。我没有见过哪个做web的把HTTP和HTML混为一坛，对于POST和GET的区别补充一点，如果你的应用程序使了web容器，以POST方式请求则会执行入口程序的POST方法 GET请求则会执行入口程序的GET方法，就是java c的main入口一样的，

1 楼 yaren 2012-07-23  

水淫挺不咚，但四，好腻害的样机~~~~