4月18

常用状态码：

200 请求成功

301 永久重定向

302 临时重定项

400 Bad Request 客户端请求错误

401 Unauthorized

403 Forbidden

404 请求的资源不存在

405 不被允许的请求⽅法

安全体示：skop-Ip地址加入白名单

415:只有请求头不对

500 服务器内部错误

504 GateWay Timeout

504 网关超时—》不一定是程序员代码的问题，也可能是第三方的问题

1、状态码 2、响应头 3、响应数据

201 created :添加资源成功

204 Not Content ：删除资源成功

 

所有的400，都是客户端的问题

1、请求头不对 2、请求参数不对

 

401、403问题的解决方法：

认证（授权）： 1、基本 basic 2、常规 digest 3、自定义 4、oauth2.0 (微信)

 

cookie: 反爬虫 ,认证授权

referer：请求目标地址是从哪里来的 content-type:代表的是什么样的数据格式 user-agent：代表的是访问目标服务器，是通过什么来访问

 

响应头

content-type:返回的响应数据是什么样的数据格式 JSON XML HTML

Set-cookie:服务端把生成的认证凭证信息返回给客户端

HTTP是一个无状态的协议，所以也就导致了COOKIE技术的发展通过COOKIE能够记下用户操作的行为状态，但是COOKIE他是存储在客户端的，所以就不安全，为了解决安全的问题，SESSION诞生，SESSION他是存储在服务器，相对来说比较安全，后面移动互联网诞生，就有了TOKEN,TOKEN本质上是SESSION原理来实现，他成为一个令牌。TOKEN的实现技术是JWT的技术

COOKIE:

1.存储在客户端

2.不安全

以登录为案列来说明COOKIE流程：

1.客户端输入账户密码登陆成功

2.在服务器生成COOKIE的信息，通过响应中的SET-COOKIE把生成的COOKIE返回给客户端

3.客户端在下次请求的时候，通过请求头中的COOKIE带上发送给服务端，服务端内部进行验证

 

SESSION流程：

 

 

1.客户端输入账户密码登录

2.在服务端会生成SESSIONID，同时存储在服务端本地，通过相应头中的SET-COOKILE把生成的SESSIONID返回给客户端

3.客户端接受到SESSIONID后

4.客户端再次请求服务端（比如访问个人主页），会在请求头的COOKIE中带SESSIONID发送给服务端

5.服务端接收到客户端发送过来的SESSIONID，与存储在服务端本地的SESSIONID之间会进行对比，如果一直，允许访问个人主页，如果不一样就会重订向到登陆的页面

 

 

 

TOKEN特点：

 

 

1.每次登陆成功后，生成的TOKEN都是不一样的

2.返回的token是一个随机的字符串