关于HTTP 请求方式: GET和POST的比较的本质

一,一般现在流传的HTTP请求:GET和POST的比较是这样的:

GET和POST是HTTP的两个常用方法。

 

什么是HTTP?

超文本传输协议(HyperText Transfer Protocol -- HTTP)是一个设计来使客户端和服务器顺利进行通讯的协议。

HTTP在客户端和服务器之间以request-responseprotocol(请求-回复协议)工作。

 

GET- 从指定的服务器中获取数据

POST- 提交数据给指定的服务器处理

 

GET方法:

使用GET方法时,查询字符串(键值对)被附加在URL地址后面一起发送到服务器:

/test/demo_form.jsp?name1=value1&name2=value2

特点:

·        GET请求能够被缓存

·        GET请求会保存在浏览器的浏览记录中

·        以GET请求的URL能够保存为浏览器书签

·        GET请求有长度限制

·        GET请求主要用以获取数据

POST方法:

使用POST方法时,查询字符串在POST信息中单独存在,和HTTP请求一起发送到服务器:

POST/test/demo_form.jsp HTTP/1.1

Host:w3schools.com

name1=value1&name2=value2

特点:

·        POST请求不能被缓存下来

·        POST请求不会保存在浏览器浏览记录中

·        以POST请求的URL无法保存为浏览器书签

·        POST请求没有长度限制

GET和POST的区别:

 

GET

POST

点击返回/刷新按钮

没有影响

数据会重新发送(浏览器将会提示用户“数据被从新提交”)

添加书签

可以

不可以

缓存

可以

不可以

编码类型(Encoding type)

application/x-www-form-urlencoded

application/x-www-form-urlencoded or multipart/form-data. 请为二进制数据使用multipart编码

历史记录

没有

长度限制

没有

数据类型限制

只允许ASCII字符类型

没有限制。允许二进制数据

安全性

查询字符串会显示在地址栏的URL中,不安全,请不要使用GET请求提交敏感数据

因为数据不会显示在地址栏中,也不会缓存下来或保存在浏览记录中,所以看POST求情比GET请求安全,但也不是最安全的方式。如需要传送敏感数据,请使用加密方式传输

可见性

查询字符串显示在地址栏的URL中,可见

查询字符串不会显示在地址栏中,不可见

其他HTTP请求方式

方式

描述

HEAD

与GET请求类似,不同在与服务器只返回HTTP头部信息,没有页面内容

PUT

上传指定URL的描述

DELETE

删除指定资源

OPTIONS

返回服务器支持的HTTP方法

CONNECT

转换为透明TCP/IP隧道的连接请求

二,本质上,这些并不是HTTP的GET和POST两者请求的区别,这些区别是建立在HTML标准对于HTTP协议的用法的约定之上的。

1. GETPOST与数据如何传递没有关系

GETPOST是由HTTP协议定义的。在HTTP协议中,MethodDataURL Body Header)是正交的两个概念,也就是说,使用哪个Method与应用层的数据如何传输是没有相互关系的。

HTTP没有要求,如果MethodPOST数据就要放在BODY中。也没有要求,如果MethodGET,数据(参数)就一定要放在URL中而不能放在BODY中。

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

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

2. HTTP协议对GETPOST都没有对长度的限制

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

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

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

安全不安全和GETPOST没有关系

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

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

防君子不防小人;中国小白多,能防小白用户就行了。

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

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

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

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

我日啊。



  • 2
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

愚人节第二天

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值