以下内容均是阅读《图解http》过程中摘抄的自用总结,会持续更新
目录
1.状态码
状态码 | 原因短语 | 含义 |
---|---|---|
200 | OK | 请求正常处理 |
204 | No Content | 请求处理成功,但没有资源可返回 |
206 | Partial Content | 范围请求成功 |
301 | Moved Permanently | 永久性重定向 |
302 | Found | 临时性重定向 |
303 | See Other | |
304 | Not Modified | 资源已找到,但是不符合条件请求 |
307 | Temporary Redirect | 临时重定向 |
400 | Bad Request | 请求报文出现语法错误 |
401 | Unauthorized | Http认证失败 |
403 | Forbidden | 资源不允许访问 |
404 | Not Found | 服务器没有请求的资源 |
500 | Internal Server Error | 服务器端资源故障 |
503 | Service Unavailable | 服务器超负载或正在停机维护 |
2.http首部字段
(1)http请求报文
包含方法、URI、http版本、http首部字段
如下是访问http://hackr.jp的请求报文的首部信息
GET / HTTP/1.1
Host:hacker.jp
User-Agent:Mozilla/5.0 (Winsows NT 6.1; WOW64; rv:13.0) Gecko/=>20100101 Firefox/13.0
Accept: text/html.application/xhtml+xml,application/xml;q=0.9,=>*/*; q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
If-Modified-Since: Fri, 31 Aug 2007 02:02:20 GMT
If-None-Match: "45bae1-16a-46d776ac"
Cache-Control: max-age=0
(2)http的响应报文
包含http版本、状态码、http首部字段构成
如下是响应http://hackr.jp的报文首部
HTTP/1.1 304 Not Modified
Date: Thu 07 Jun 2012 07:21:36 GMT
Server: Apache
Connection: close
Etag: "45bael-16a-46d776ac"
(3)四种首部字段类型
以下打*的字段属于逐跳首部字段
1)通用首部字段
在请求报文和响应报文中均会使用
首部字段名 | 说明 | |
---|---|---|
Cache-Control | 控制缓存行为 | |
*Connection | 逐跳首部、连接管理 | |
Date | 创建报文的日期时间 | |
Pragma | 报文指令 | |
*Trailer | 报文末端的首部一览 | |
*Transfer-Encoding | 指定报文主体的传输编码方式 | |
* Upgrade | 升级为其他协议 | |
Via | 代理服务器的相关信息 追踪客户端与服务器的请求和响应报文的传输路径 | |
Warning | 错误通知 | 110 响应过期 111 代理再验证资源有效性时失败 112 代理与互联网连接被故意切断 113 响应的使用期超过24小时 199 任意的警告内容 214 代理对内容编码或媒体类型等执行了某些处理 299 任意的内容警告 |
2)请求首部字段
首部字段名 | 说明 | |
---|---|---|
Accept | 用户代理可处理的媒体类型 | 使用q=x表示权重给媒体类型增加优先级 x ∈ \in ∈ [0, 1.0] |
Accept-Charest | 优先的字符集 | gzip, cpmpress, deflate, identity |
Accept-Encoding | 优先的内容编码 | |
Accept-Language | 优先的自然语言 | |
Authorization | Web认证信息 | 客户端与服务器的认证 |
Expect | 期待服务器的特定行为 | |
From | 用户的电子邮箱地址 | |
Host | 请求的资源所在服务器 | |
If-Match | 比较实体标记(ETag | |
If-Modified-Since | 比较资源的更新时间 | |
If-None-Match | 比较实体标记(与If-Match相反) | |
If-Range | 资源未更新时发送实体Byte的范围请求 | |
If-Unmodified-Since | 比较资源的更新时间 (与If-Modified-Since相反) | |
Max-Forwards | 最大传输逐跳数 | |
*Proxy-Authorization | 代理服务器要求客户端的认证信息 | 客户端与代理之间 |
Range | 实体的字节请求范围 | |
Referer | 告知服务器请求的原始资源的URI | |
*TE | 传输编码的优先级 | |
User-Agent | HTTP客户端程序的信息 | 传递创建请求的浏览器和用户代理名称 |
3)响应首部字段
首部字段名 | 说明 | |
---|---|---|
Accept-Ranges | 是否接受字节范围请求 | |
Age | 推算资源创建经过时间 | |
ETag | 资源的匹配信息 | |
Location | 令客户端重定向至指定URI | |
*Proxy-Authenticate | 代理服务器对客户端的认证信息 | |
Retry-After | 对再次发起请求的时机要求 | |
Server | HTTP服务器的安装信息 | |
Vary | 代理服务器缓存的管理信息 | |
WWW-Authenticate | 服务器对客户端的认证信息 |
4)实体首部字段
实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首部,用于补充内容的更新时间等与实体相关的信息
首部字段名 | 说明 | |
---|---|---|
Allow | 资源可支持的HTTP方法 | GET, HEAD等 |
Content-Encoding | 实体主体适用的编码方式 | gzip, compress, deflate, identity等 |
Content-Language | 实体主体的自然语言 | |
Content-Length | 实体主体的大小(单位:字节) | |
Content-Locarion | 代替对应资源的URI | |
Content-MD5 | 实体主体的报文摘要 | 可以用来检查报文主体在传输过程中是否保持完整 |
Content-Range | 实体主体的位置范围 | |
Content-Type | 实体主体的媒体类型 | |
Expires | 实体主体过期的日期时间 | |
Last-Modified | 资源的最后修改日期时间 |
5)补充
[1] Cache-Control:可以操作缓存
缓存请求指令
指令 | 参数 | 说明 |
---|---|---|
no-cache | - | 中间的服务器必须把客户端请求转发给源服务器 |
no-store | - | 请求或响应包含机密信息,缓存不能本地存储请求或响应的任一部分 |
max-age = [秒] | 必需 | 响应的最大Age值 当缓存资源的缓存时间数值比指定时间的数值小,则客户端接受缓存资源。 当指定max-age=0时,缓存服务器需要将请求转发给源服务器 |
max-stale ( = [秒] ) | 可省略 | 接收已过期的响应 |
min-fresh = [秒] | 必需 | 期望在指定时间内的响应仍有效 要求缓存服务器返回至少还未过指定时间的缓存资源 |
no-transform | 无 | 代理不可更改媒体类型 |
only-if-cached | 无 | 从缓存获取资源 |
cached-extrension | - | 新指令标记(token) |
缓存响应指令
指令 | 参数 | 说明 |
---|---|---|
public | 无 | 可向任意方提供响应的缓存 |
private | 可省略 | 仅向特定用户返回响应 |
no-cache | 可省略 | 缓存服务器不可对资源进行缓存; 若包含参数值,则客户端也不可以缓存资源; 若无参数,客户端可以缓存资源 |
no-store | 请求或响应包含机密信息,缓存不能本地存储请求或响应的任一部分 | |
no-transform | - | 代理不可更改媒体类型 |
must-revalidate | - | 可缓存但必须再向源服务器进行确认 |
proxy-revalidate | - | 要求中间缓存服务器对缓存的响应有效性再进行确认 |
max-age= [秒] | 必需 | 响应的最大Age值 缓存服务器不对资源的有效性再作确认,且max-age表示资源保存为缓存的最长时间 |
s-max-age = [秒] | 必需 | 指定缓存期限,公共缓存服务器响应的最大Age值 向同一用户重复返回响应的服务器来说,这个指令无用 使用这个指令会使得Expires首部字段和max-age指令的处理 |
cache-extension | - | 新指令标记(token) |
[2] Connection
控制不再转发给代理的首部字段
客户端(Connection字段表示删除Upgrade字段)
GET / HTTP/1.1
Upgrade: HTTP/1.1
Connection: Upgrade
代理服务器转发:
GET / HTTP/1.1
管理持久连接
Connection: Keep-Alive
Connection: close
(4)为Cookie服务的首部字段
首部字段名 | 说明 | 首部类型 |
---|---|---|
Set-Cookie | 开始状态管理所使用的Cookie信息 | 响应首部字段 |
Cookie | 服务器接收到的Cookie信息 | 请求首部字段 |
字段的属性和值
属性 | 说明 |
---|---|
NAME=VALUE | 赋予Cookie的名称和其值(必需项) |
expires=DATE | Cookie的有效期(若不明确指定则默认为浏览器关闭前为止 |
path=PATH | 将服务器上的文件目录作为Cookie的适用对象(若不指定则默认为文档所在的文件目录) |
domain=域名 | 作为Cookie适用对象的域名(若不指定则默认为创建Cookie的服务器的域名) |
secure | 仅在HTTPS安全通信时才会发送Cookie |
HttpOnly | 加以限制,使Cookie不能被JavaScript脚本访问 |
(5)其他首部字段
字段名 | 值 | 说明 |
---|---|---|
X-Frame-Options | deny 拒绝 sameorigin同源域名下的页面匹配时许可 | 控制网站内容在其他Web网站的Frame标签内的显示问题 |
X-XSS-Protection | 0: 将XSS过滤设置成无效状态 1: 将XSS过滤设置成有效状态 | 属于http响应首部,是针对跨站脚本攻击的一种对策,用于控制浏览器XSS防护机制的开关 |
DNT | 0: 同意被追踪 1:拒绝被追踪 | Do Not Track 拒绝个人信息被收集,是拒绝精准广告追踪的方法 |
P3P | 可以将隐私变成仅供程序理解的形式,用于保护用户隐私 |
3.https的安全通信机制
步骤1:客户端发送ClientHello报文开始SSL通信。报文包含客户端支持的SSL的指定版本、加密组件列表
步骤2:服务器可进行SSL通信时,服务器以ServerHello报文为应答。报文包含SSL版本和加密组件列表,这里的加密组件是从客户端的加密组件中筛选出来的
步骤3:服务器发送Certificate报文,报文包含公开密钥证书
步骤4:服务器发送ServerHelloDone报文通知客户端,最初阶段的SSL握手协商部分结束
步骤5:SSL第一次握手结束之后,客户端以ClientKeyExchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-mastersecret的随机密码串。该报文已用步骤3中的公开密钥进行加密
步骤6:接着客户端继续发送ChangeCipherSpec报文。该报文会提示服务器,在此报文之后的通信会采用Pre-master secret密钥加密
步骤7:客户端发送finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功,要以服务器是否能够正确解密该报文作为判定标准
步骤8:服务器同样发送Change Cipher Spec报文
步骤9:服务器同样发送Finished报文
步骤10:服务器和客户端的DFinished报文交换完毕之后,SSL连接就算建立完成。当然,通信会受到SSL的保护。从此处开始进行应用层协议的通信,即发送HTTP请求
步骤11:应用层协议通信,即发送HTTP响应
步骤12:最后由客户端断开连接。断开连接时,发送close_notify报文
4. HTTP/1.1使用的认证方式
4.1 BASIC认证
步骤1: 当请求的资源需要BASIC认证时,服务器会随状态码401Authorization Required,返回带www-Authenticate首部字段的响应。该字段内包含认证的方式内BASIC及Request-URI安全域字符串realm。
步骤2:接收到状态码401的客户端为了通过BASIC认证,需要将用户ID及密码发送给服务器。发送的字符串内容时由用户ID和密码构成,两者中间以冒号(:)连接后,再经过Base64编码处理。
假设用户ID为guest,密码是guest,连接起来就会形成guest:guest这样的字符串。然后经过Base64编码,最后的结果即是Z3Vlc3Q6Z3Vlc3Q6=。把这串字符串写入首部字段Authorization后,发送请求。
当用户代理为浏览器时,用户仅需输入用户ID和密码即可,之后,浏览器会自动完成到Base64编码的转换工作。
步骤3接收到包含首部字段Authorization请求的服务器,会对认证信息的正确性进行验证。如验证通过,则返回一条包含Request-URI资源的响应。
4.2 DIGEST认证
步骤1:请求需认证的资源时,服务器会随着状态码401Authorization Required,返回带WWW-Authenticate首部字段的响应。该字段内包含质问响应方式认证所需的临时质询码(随机数,nonce),首部字段WWW-Authenticate内必需包含realm和nonce这两个字段的信息。客户端就是依靠服务器会送这两个值进行认证的。
nonce是一种每次随返回的401响应生成的任意随机字符串。
步骤2:接收到401状态的客户端,返回的响应中包含DIGEST认证必须的首部字段Authorization信息。首部字段Authorization内必须包含username\realm\nonce\uri和response的字段信息。其中,realm和nonce就是之前从服务器接收到的响应中的字段。
步骤3:接收到包含首部字段Autthentication请求的服务器,会确认认证信息的正确性。认证通过后则返回包含Request-URI资源的响应。
4.3 SSL客户端认证
步骤1:接收到需要认证资源的请求,服务器会发送Certificate报文,要求客户端提供客户端证书
步骤2:用户选择将发送的客户端证书后,客户端会把客户端证书信息以Client Certificate报文方式发送给服务器。
步骤3:服务器验证客户端证书验证通过后方可领取证书内容客户端的公开密钥,然后开始HTTPS加密通信
4.4 基于表单认证-Session及Cookie
步骤1:客户端把用户ID和密码等登录信息放入报文的实体部分,通常是以POST方法把请求发送给服务器。而这是,会使用HTTPS通信来进行HTML表单画面的显示和用户输入数据的发送。
步骤2:服务器会发放用以识别用户的Seesion ID。通过验证从客户端发送过来的登录信息进行身份认证,然后把用户的认证状态与Session ID绑定后记录在服务器端。
步骤3:客户端接收到从服务器端发来的Session ID后,将其作为Cookie保存在本地。
——————————————————————————
P167 第8章 确认访问用户身份的认证