HTTP 方法:GET 对比 POST
在了解get、POST区别之前先了解一下http协议。
1. Http协议简介
1.什么是Http协议
HTTP,超文本传输协议(HyperText Transfer Protocol)是互联网上应用最为广泛的 一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。是建立在TCP/IP协议之上的应用层规范。
2.Http协议的组成
Http协议由Http请求和Http响应组成,当在浏览器中输入网址访问某个网站时, 你的浏览器会将你的请求封装成一个Http请求发送给服务器站点,服务器接收到请 求后会组织响应数据封装成一个Http响应返回给浏览器。即没有请求就没有响应。
3.Http请求
编辑一个form.html的表单页面,如下:
<!doctype html> <html> <head> <meta http-equiv="Content-Type" contexnt="text/html; charset=UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> </head> <body style="font-size: 40px; text-align: center;"> <form action="/weixin/test/test.html" method="post"> <input name="name" value="zs"/> <input name="age" value="25"/> <input type="submit"/> </form> </body> </html>
点击提交按钮,用抓包工具分析:
1)请求行
请求方式:POST、GET
请求的资源:/DemoEE/form.html
协议版本:HTTP/1.1
HTTP/1.0,发送请求,创建一次连接,获得一个web资源,连接断开。
HTTP/1.1,发送请求,创建一次连接,获得多个web资源,保持连接。
2)请求头
请求头是客户端发送给服务器端的一些信息,使用键值对表示key:value
常见请求头 |
描述 (红色掌握,其他了解) |
Referer |
浏览器通知服务器,当前请求来自何处。如果是直接访问,则不会有这个头。常用于:防盗链 |
If-Modified-Since |
浏览器通知服务器,本地缓存的最后变更时间。与另一个响应头组合控制浏览器页面的缓存。 |
Cookie |
与会话有关技术,用于存放浏览器缓存的cookie信息。 |
User-Agent |
浏览器通知服务器,客户端浏览器与操作系统相关信息 |
Connection |
保持连接状态。Keep-Alive 连接中,close 已关闭 |
Host |
请求的服务器主机名 |
Content-Length |
请求体的长度 |
Content-Type |
如果是POST请求,会有这个头,默认值为application/x-www-form-urlencoded,表示请求体内容使用url编码 |
Accept: |
浏览器可支持的MIME类型。文件类型的一种描述方式。 MIME格式:大类型/小类型[;参数] 例如: text/html ,html文件 text/css,css文件 text/javascript,js文件 image/*,所有图片文件 |
Accept-Encoding |
浏览器通知服务器,浏览器支持的数据压缩格式。如:GZIP压缩 |
Accept-Language |
浏览器通知服务器,浏览器支持的语言。各国语言(国际化i18n) |
3)请求体
当请求方式是post的时,请求体会有请求的参数,格式如下:
name=zs&age=25
(4)如果请求方式为get,那么请求参数不会出现在请求体中,会拼接在url地址后面(默认为Get方式)
<!doctype html> <html> <head> <meta http-equiv="Content-Type" contexnt="text/html; charset=UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> </head> <body style="font-size: 40px; text-align: center;"> <form action="/weixin/test/test.html"> <input name="name" value="zs"/> <input name="age" value="25"/> <input type="submit"/> </form> </body> </html>
结果:
4.Http响应
1)响应行
Http协议
状态码:
常用的状态码如下:
200 :请求成功。
302 :请求重定向。
304 :请求资源没有改变,访问本地缓存。
404 :请求资源不存在。通常是用户路径编写错误,也可能是服务器资源已删除。
500 :服务器内部错误。通常程序抛异常。
状态信息:状态信息是根据状态码变化而变化的
2)响应头
响应也都是键值对形式,服务器端将信息以键值对的形式返回给客户端
常见请求头 |
描述 |
Location |
指定响应的路径,需要与状态码302配合使用,完成跳转。 |
Content-Type |
响应正文的类型(MIME类型) 取值:text/html;charset=UTF-8 |
Content-Disposition |
通过浏览器以下载方式解析正文 取值:attachment;filename=xx.zip |
Set-Cookie |
与会话相关技术。服务器向浏览器写入cookie |
Content-Encoding |
服务器使用的压缩格式 取值:gzip |
Content-length |
响应正文的长度 |
Refresh |
定时刷新,格式:秒数;url=路径。url可省略,默认值为当前页。 取值:3;url=www.itcast.cn //三秒刷新页面到www.itcast.cn |
Server |
指的是服务器名称,默认值:Apache-Coyote/1.1。可以通过conf/server.xml配置进行修改。<Connector port="8080" ... server="itcast"/> |
Last-Modified |
服务器通知浏览器,文件的最后修改时间。与If-Modified-Since一起使用。 |
3)响应体
响应体是服务器回写给客户端的页面正文,浏览器将正文加载到内存,然后解析渲染 显示页面内容
2. GET和POST区别
两种最常用的 HTTP 方法是:GET 和 POST。
在客户机和服务器之间进行请求-响应时,两种最常被用到的方法是:GET 和 POST。
- GET - 从指定的资源请求数据。
- POST - 向指定的资源提交要被处理的数据
1. 比较 GET 与 POST(w3school描述如下)
下面的表格比较了两种 HTTP 方法:GET 和 POST。
GET | POST | |
---|---|---|
后退按钮/刷新 | 无害 | 数据会被重新提交(浏览器应该告知用户数据会被重新提交)。 |
书签 | 可收藏为书签 | 不可收藏为书签 |
缓存 | 能被缓存 | 不能缓存 |
编码类型 | application/x-www-form-urlencoded | application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。 |
历史 | 参数保留在浏览器历史中。 | 参数不会保存在浏览器历史中。 |
对数据长度的限制 | 是的。当发送数据时,GET 方法向 URL 添加数据;URL 的长度是受限制的(URL 的最大长度是 2048 个字符)。 | 无限制。 |
对数据类型的限制 | 只允许 ASCII 字符。 | 没有限制。也允许二进制数据。 |
安全性 |
与 POST 相比,GET 的安全性较差,因为所发送的数据是 URL 的一部分。 在发送密码或其他敏感信息时绝不要使用 GET ! |
POST 比 GET 更安全,因为参数不会被保存在浏览器历史或 web 服务器日志中。 |
可见性 | 数据在 URL 中对所有人都是可见的。 | 数据不会显示在 URL 中。 |
现在我们知道了两种方法本质上是 TCP 连接,没有区别。但如果不按规范来也是可以的,可以在 URL 上写参数,然后方法使用 POST;也可以在 Body 写参数,然后方法使用 GET。当然,这需要服务端支持。
2. 更多可能的问题:
(1)方法参数写法是固定的吗?
在约定中,我们的参数是写在 ? 后面,用 & 分割。我们知道,解析报文的过程是通过获取 TCP 数据,用正则等工具从数据中获取 Header 和 Body,从而提取参数。
比如header请求头中添加token,来验证用户是否登录等权限问题。
也就是说,我们可以自己约定参数的写法,只要服务端能够解释出来就行。
(2)GET 方法的长度限制是怎么回事?
首先说明一点,HTTP 协议没有 Body 和 URL 的长度限制,对 URL 限制的大多是浏览器和服务器的原因。
浏览器原因就不说了,服务器是因为处理长 URL 要消耗比较多的资源,为了性能和安全(防止恶意构造长 URL 来攻击)考虑,会给 URL 长度加限制。
(3)POST 方法比 GET 方法安全?
有人说POST 比 GET 安全,因为数据在地址栏上不可见。然而,从传输的角度来说,他们都是不安全的,因为 HTTP 在网络上是明文传输的,只要在网络节点上捉包,就能完整地获取数据报文。要想安全传输,就只有加密,也就是 HTTPS。
其他 HTTP 请求方法
下面的表格列出了其他一些 HTTP 请求方法:
方法 | 描述 |
---|---|
HEAD | 与 GET 相同,但只返回 HTTP 报头,不返回文档主体。 |
PUT | 上传指定的 URI 表示。 |
DELETE | 删除指定资源。 |
OPTIONS | 返回服务器支持的 HTTP 方法。 |
CONNECT | 把请求连接转换到透明的 TCP/IP 通道。 |
补充:post的四种提交方式
协议规定 POST提交的数据必须放在消息主体(entity-body)中,但协议并没有规定数据必须使用什么编码方式。
后端代码如下:
/** * 接收表单数据(这里用request直接接收) * * @param request * @return */ @RequestMapping("/test") @ResponseBody public String test(HttpServletRequest request, HttpServletResponse response) { String method = request.getMethod(); System.out.println("request.getMethod(): " + method); Enumeration<String> parameterNames = request.getParameterNames(); while (parameterNames.hasMoreElements()) { String parameterName = (String) parameterNames.nextElement(); String parameterValue = request.getParameter(parameterName); System.out.println(" parameterName: " + parameterName + " , parameterValue: " + parameterValue + " "); } return "success"; }
测试四种提交方式:
1. application/x-www-form-urlencoded
这应该是最常见的 POST 提交数据的方式了。浏览器的原生 form 表单,如果不设置 enctype 属性,那么最终就会以 application/x-www-form-urlencoded 提交数据。
<form action="/weixin/test/test.html" method="post"> <input name="name" value="zs-张三"/> <input name="age" value="25"/> <input type="submit"/> </form>
结果:
后台:
request.getMethod(): POST
parameterName: name , parameterValue: zs-张三
parameterName: age , parameterValue: 25
很多时候,我们用 Ajax 提交数据时,也是使用这种方式。例如 JQuery 的 Ajax,Content-Type 默认值都是「application/x-www-form-urlencoded;charset=utf-8」,当然可以自己指定。
2. multipart/form-data
这又是一个常见的 POST 数据提交的方式。我们使用表单上传文件时,必须让 form 的 enctyped 等于这个值。
<form action="/weixin/test/test.html" method="post" enctype="multipart/form-data"> <input name="name" value="zs-张三"/> <input name="age" value="25"/> <input name="file" type="file"/> <input type="submit"/> </form>
结果:
3. application/json
application/json 这个 Content-Type 作为响应头大家肯定不陌生。实际上,现在越来越多的人把它作为请求头,用来告诉服务端消息主体是序列化后的 JSON 字符串。由于JSON 规范的流行,除了低版本 IE 之外的各大浏览器都原生支持 JSON.stringify,服务端语言也都有处理 JSON 的函数,使用 JSON 不会遇上什么麻烦。
这种一般在JSON中发送的形式比较多,例如:
function submitForm() { var jsonObj = {"name": "zs-张三", "age": "25"}; jsonObj = JSON.stringify(jsonObj); $.ajax({ url: '/weixin/test/test.html', data: jsonObj, type: "POST", contentType: 'application/json' }); }
后端代码:
/** * 接收表单数据(这里用request直接接收) * * @param request * @return */ @RequestMapping("/test") @ResponseBody public String test(@RequestBody String json) { System.out.println(json); return "success"; }
结果:
后端结果:
{"name":"zs-张三","age":"25"}
4. text/xml
它是一种使用 HTTP 作为传输协议,XML 作为编码方式的远程调用规范。
补充:持久链接
我们知道 HTTP 协议采用“请求-应答”模式,当使用普通模式,即非 Keep-Alive 模式时,每个请求/应答客户和服务器都要新建一个连接,完成之后立即断开连接(HTTP协议为无连接的协议);当使用 Keep-Alive 模式(又称持久连接、连接重用)时,Keep-Alive 功能使客户端到服务器端的连接持续有效,当出现对服务器的后继请求时,Keep-Alive 功能避免了建立或者重新建立连接。当客户端发送另外一个请求时,就使用这条已经建立的连接。
HTTP Keep-Alive 简单说就是保持当前的TCP连接,避免了重新建立连接。
HTTP 长连接不可能一直保持,例如响应头中的Keep-Alive: timeout=5, max=100,表示这个TCP通道可以保持5秒,max=100,表示这个长连接最多接收100次请求就断开。
(1)对于Http1.0
使用HTTP/1.0的客户端在首部中加上”Connection:Keep-Alive”,请求服务端将一条连接保持在打开状态。服务端如果愿意将这条连接保持在打开状态,就会在响应中包含同样的首部。如果响应中没有包含”Connection:Keep-Alive”首部,则客户端会认为服务端不支持keep-alive,会在发送完响应报文之后关闭掉当前连接。
(2)对于Http 1.1
HTTP/1.1采取持久连接的方式替代了Keep-Alive。HTTP/1.1的连接默认情况下都是持久连接。如果要显式关闭,需要在报文中加上Connection:Close首部。
即在HTTP/1.1中,所有的连接都进行了复用。
例如:
(1)关闭长连接:
response.setHeader("Connection", "close");
(2)将长链接限定为94个请求
response.setHeader("Keep-Alive", "timeout=5, max=94");
通过wireshark抓包分析长链接。