网络协议-HTTP

问题

• 请求重定向头部
  • 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