POST 方法比 GET 方法安全?
从传输的角度来说,他们都是不安全的,因为 HTTP 在网络上是明文传输的,只要在网络节点上捉包,就能完整地获取数据报文;
安全传输,就只有加密,也就是 HTTPS。
GET 方法的长度限制是怎么回事?
首先说明一点,HTTP 协议没有 Body 和 URL 的长度限制,对 URL 限制的大多是浏览器和服务器的原因。
浏览器原因就不说了,服务器是因为处理长 URL 要消耗比较多的资源,为了性能和安全(防止恶意构造长 URL 来攻击)考虑,会给 URL 长度加限制。
IE浏览器对URL的最大限制为2083个字符
Firefox(Browser):对于Firefox浏览器URL的长度限制为65,536个字符。
Safari(Browser):URL最大长度限制为 80,000个字符。
Opera(Browser):URL最大长度限制为190,000个字符。
Google(chrome):URL最大长度限制为8182个字符。
Apache(Server):能接受最大url长度为8,192个字符。
Microsoft Internet Information Server(IIS):能接受最大url的长度为16,384个字符。
url的最好不好超过最低标准的2083个字符(2k+35),中文的传递,一个汉字最终编码后的字符长度是9个字符;1.浏览器。
据说早期的浏览器会对URL长度做限制。
据说IE对URL长度会限制在2048个字符内(流传很广,而且无数同事都表示认同)。
但我自己试了一下,我构造了90K的URL通过IE9访问live.com,是正常的。
网上的东西,哪怕是维基百科(Wikipedia)上的,也不能信。
2.服务器。
URL长了,对服务器处理也是一种负担。
原本一个会话就没有多少数据,现在如果有人恶意地构造几个几M大小的URL,并不停地访问你的服务器。
服务器的最大并发数显然会下降。另一种攻击方式是,把告诉服务器Content-Length是一个很大的数,然后只给服务器发一点儿数据,嘿嘿,服务器你就傻等着去吧。
哪怕你有超时设置,这种故意的次次访问超时也能让服务器吃不了兜着走。
有鉴于此,多数服务器出于安全啦、稳定啦方面的考虑,会给URL长度加限制。
但是这个限制是针对所有HTTP请求的,与GET、POST没有关系。
POST 方法会产生两个TCP数据包?
post 会将 header 和 body 分开发送,先发送 header,服务端返回 100 状态码再发送 body。
HTTP 协议中没有明确说明 POST 会产生两个 TCP数据包,而且实际测试(Chrome)发现,header 和 body 不会分开发送。
所以,header 和 body 分开发送是部分浏览器或框架的请求方法,不属于 post 必然行为。