问题
- 请求重定向头部
- 302，Location=url
- Refresh=5;URL=url
常用头部
长连接
- HTTP1.1以前
- Connection:Keep-Alive
- 弊端：哑代理
- HTTP1.1
- 默认长连接
- Connection:Close
- 原理
- 基于TCP的长连接，通俗的说就是socket不关闭，可以反复用
概述
- Request For Comments（RFC）
- 一系列以编号排定的文件；收集互联网相关信息，以及UNIX和互联网社区的软件文件
- 请求组成
- 首行 + 请求头 + 空行 + 请求体
- 响应组成
- 首行 + 响应头 + 空行 + 响应体
- 请求方法
- GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS, TRACE
- POST
- 目标是行为处理器
- 非幂等
- PUT与PATCH
- 所请求目标地址都是直接指向资源
- PUT
- 替换资源
- 幂等
- PATCH
- 更新部分资源
- 非幂等
- 问题：PATCH为什么是非幂等的？
- POST非幂等可以理解，因为请求服务器执行一个动作，多次请求可能导致动作多次执行
- 而PATCH请求的目标是一个资源的，如果它只是更新一个资源，不执行其它动作，又何来不幂等呢？
- 其实我忽略了一个问题，PATCH方法和POST方法有个很相似的地方，它们的实体部分都是结构化的数据
- POST的实体结构一般是 multipart/form-data 或 application/x-www-form-urlencoded
- PATCH的实体结构则根据其它规范定义
- 这和PUT方法的无结构实体相比就是最大的区别；PUT方法的实体无结构，直接把实体部分数据替换到服务器的资源上
- 而PATCH提供的实体则需要根据程序或其它协议的定义，解析后在服务器上执行，以此来修改服务器上的数据
- 也就是说，PATCH请求是会执行某个程序的；如果重复提交，程序可能执行多次，对服务器上的资源就可能造成额外的影响，这就可以解释它为什么是不幂等的了
- 举个例子
- 服务器上有个资源/abc.int，里面存放一个整数，值为 1
- 也就是说，GET这个资源的话，服务器响应的实体只包含了1这个数字
- 现在自己定义当提交PATCH请求时，实体匹配^\s+\d+$的格式时就对服务器资源中的数字执行一个加法操作
- 于是当客户端向/abc.int地址发起PATCH请求，实体部分为+3之后，服务器的/abc.int资源中的数据就变成4
- 如果客户端不小心重复提交了PATCH请求，那么+3就会被再执行一次，这个资源的数据就变成7
