HTTP
协议相关的文章cookie
做状态管理get
,post
等注:若HTTP首部字段重复了的话,不同的浏览器处理机制不一样
2xx的响应结果就代表请求被正常处理了
3xx的响应结果就表明浏览器需要执行某些特殊的处理以正确处理请求
4xx的响应结果就表明客户端是发生错误的原因所在
5xx的响应结果就表明服务器本身发生错误
Retry-After
这个字段再返回给客户端HTTP1.1 规定了 以下47种首部字段
首部字段 | 解释 |
---|---|
1. Cache-Control | 控制缓存的行为 |
2. Connection | 逐跳首部、连接的管理 |
3. Date | 创建报文的日期和时间 |
4. Pragma | 报文指令 |
5. Trailer | 报文末端的首部一览 |
6. Transfer-Encoding | 指定报文主体的传输编码方式 |
7. Upgrade | 升级为其他协议 |
8. Via | 代理服务器的相关信息 |
9. Warning | 错误通知 |
下面我们来看挑几个重要的属性来看下~
GET / HTTP/1.1
Upgrade: HTTP/1.1 // 就会把次字段删除后再从代理服务器转发出去
Connection: Upgrade // 不再转发的首部字段名
Connction: Keep-Alive
Connction: close
HTTP/1.1
之前版本遗留的字段,仅仅是为了与HTTP/1.0向后兼容而定义Pragm:no-cache
:通用首部字段,在请求头中,表示所有的中间服务器不返回缓存的资源HTTP/1.1
为基准的话,可以直接采用 Cache-Control:no-cache
Cache-Control:no-cache
Pragm:no-cache
首部字段 | 解释 |
---|---|
1.Accrpt | 用户代理可处理的媒体类型 |
2.Accrpt-Charset | 优先的字符集 |
3.Accept-Encoding | 优先的内容编码 |
4.Accept-Language | 优先的语言(自然语言) |
5.Authorization | web认证信息 |
6.Expect | 期待服务器的特定行为 |
7.From | 用户的电子邮箱地址 |
8.Host | 请求资源所在服务器 |
9.If-Match | 比较实体标记(ETag) |
10.If-Modified-Since | 比较资源的更新时间 |
11.If-None-Match | 比较实体标记(与If-Match相反) |
12.If-Range | 资源未更新时发送实体Byte的范围请求 |
13.If-Unmodified-Since | 比较资源的更新时间(与If-Modified-Since相反) |
14.Max-Forwards | 最大传输逐跳数 |
15.Proxy-Authorization | 代理服务器要求客户端的认证信息 |
16.Range | 实体的字节范围要求 |
17.Referer | 对请求中URI的原始获取方 |
18.TE | 传输编码的优先级 |
19.User-Agent | HTTP客户端程序的信息 |
If-Match
字段值跟 ETag
值匹配一致时,服务器才会接受请求412 Precondition Failed
的响应If-Match
的字段值,如果这样的话,那么服务器将会忽略ETag的值,只要资源存在就处理请求。304 Not Modified
Last-Modified
来确定If-None-Match
的字段值与ETag值不一致时,才可以处理该请求,与前文中提到的If-Match
作用相反If-Range
字段值(ETag值或者时间)和请求资源的ETag值或时间一致时,则作为范围请求处理,否则,返回全体资源412 Precondition Failed
状态响应,与If-Modified-Since
作用相反Range
字段可以指定获取资源范围Range: bytes=10001-20000
206 Partial Content
的响应。无法处理时,则会返回状态码200 OK
的响应及其全部资源首部字段名 | 解释 |
---|---|
1.Accept-Ranges | 是否接受字节范围请求 |
2.Age | 推算资源创建经过时间 |
3.ETag | 资源的匹配信息 |
4.Location | 令客户端重定向至指定URI |
5.Proxy-Authenticate | 代理服务器对客户端的认证信息 |
6.Retry-After | 对再次发起请求的时机要求 |
7.Server | HTTP服务器的安装信息 |
8.Vary | 代理服务器缓存的管理信息 |
9.WWW-Authenticate | 服务器对客户端的认证信息 |
Accept-Ranges:bytes
可以处理范围请求Accept-Ranges:none
不可以处理范围请求ETag
值,资源被更新时,ETag
值也会被更新,并没有统一的算法规则,而是由服务器来分配ETag
:无论实体发生多么细微的变化都会改变其值ETag
:只用于提示资源是否相同,只有资源发生了根本的改变才会改变ETag值,这时会在字段值最开始加W/
,
ETag:W/"XXX"
Accept-Language:en-us
字段的值相同,那么直接从缓存返回响应,否则从源服务器请求资源后再返回响应首部字段名 | 解释 |
---|---|
1.Allow | 资源可支持的HTTP方法 |
2.Content-Encoding | 实体主体适用的编码方式 |
3.Content-Language | 实体主体的自然语言 |
4.Content-Length | 实体主体的大小(单位:字节) |
5.Content-Location | 代替对应资源的URI |
6. Content-MD5 | 实体主体的报文摘要 |
7. Content-Range | 实体主体的位置范围 |
8. Content-Type | 实体主体的媒体类型 |
9.Expires | 实体主体过期的日期时间 |
10.Last-Modified | 资源的最后修改日期时间 |
属性 | 解释 |
---|---|
NAME=VALUE | 赋予Cookie的名称和其值(必需项) |
expires = DATE | Cookie的有效期(若不指定则默认为浏览器关闭为止) |
path=PATH | 将服务器上的文件目录作为Cookie的适用对象(若不指定则默认为文档所在的文件目录) |
domin=域名 | 作为Cookie适用对象的域名(若不指定则默认为创建Cookie的服务器域名) |
Secure | 仅在HTTPS安全通信时才会发送Cookie |
HttpOnly | 加以限制,使Cookie不能被JS脚本访问,主要目的是为了防止跨站脚本攻击(Cross Site Scripting,XSS)对cookie的窃取 |
thor
和JSESSIONID
这两个key的后HttpOnly
属性被打上了√,就表明,此key无法被js脚本访问,防止跨站脚本攻击(Cross Site Scripting,XSS)对cookie的窃取 我们来看下再console
控制台输入document.cookie
得出的cookie无法找到这两个key因为这个属性JSESSIONID
比较重要,存储的是sessionId,这个要是被别人拿到的话,别人就可以冒充我在网站上做某些事情了,像我自己一样请求某些数据了
我把网页上的cookie拿下来,放到postman里测试,发现和我自己在网站上请求数据是一样的
清理缓存主要就是清理cookie,抹去自己登陆痕迹以及浏览器中的资源缓存,重新请求网站资源
HTTPS是身披SSL(Secure Socket Layer)外壳的HTTP
聪明的大佬们用两种加密算法混合了一下
我曾经以为这样就万无一失了,文章也就到此结束了,可以和血包杀手愉快的timi了,可是,你有没有听说过,中间人攻击?
黑客拦截”用公开加密密钥机密后的共享密钥“后不是解密不了吗,好,那我就不拦截这个了,我拦截第一个请求好吧,我拦截服务端传给你的公开密钥,我拦截到了,我再给你个假的,(像极了《让子弹飞》中,张麻子与马邦德的关系,出任鹅城县长)。从根上就伪装成你,以后就等于我是个中间人(中转站),所有的请求,数据都要经过我,那我就可以记录下来其中你的敏感数据,可怕。