七、《图解HTTP》- HTTP首部和HTTP协作服务器(二)

简介: 七、《图解HTTP》- HTTP首部和HTTP协作服务器(二)

知识点

  1. 请求头部字段分类比较多,本章介绍了下面的首部,内容非常多,熟悉常见的请求首部即可。
  1. 首部字段介绍
  2. 非HTTP1.1 首部字段
  3. 通用首部
  4. 请求首部
  5. 响应首部
  6. 负载首部(实体首部)
  7. 其他首部字段
  1. 协作服务器指的是为了HTTP加速访问而架设的一些中间件介绍,内容介绍比较匮乏,个人也没有补充,简单浏览即可

7.3 请求首部字段

请求首部是客户端传递给服务端的字段。

image.png

7.3.1 Accept(Accept: text/html,application/xhtml+xml,application/xml;q=0.)

首部字段可以 通知服务器,用户代理能够处理的媒体类型以及媒体类型相对优先级。

  • 文本文件
  • text/html, text/plain, text/css ...
  • application/xhtml+xml, application/xml ...
  • 图片文件
  • image/jpeg, image/gif, image/png ...
  • 视频文件
  • video/mpeg, video/quicktime ...
  • 应用程序使用的二进制文件
  • application/octet-stream, application/zip ...

案例:

比如使用 type/subtype 这种形式,一次指定多种媒体类型,通过q=?指定权重值,默认权重为1,可以设置权重为三位小数。假设服务器可以一次性提供多种信息,会优先提供权重值最高的媒体类型数据。

7.3.2 Accept-Charset(Accept-Charset: iso-8859-5, unicode-1-1;q=0.8)

主要作用是用来通知服务器用户代理支持的字符集及字符集的相对优先顺序,与首部字段 Accept 相同的是,可用权重 q 值来表示相对优先级。

这个字段的主要作用是内容协商机制的服务器驱动协商

7.3.3 Accept-Encoding(Accept-Encoding: gzip, deflate)

主要作用是告知服务器用户代理支持的请求编码以及优先级顺序,支持一次性指定多级编码,编码的相关案例如下:

gzip:由文件压缩程序 gzip(GNU zip)生成的编码格式 (RFC1952),采用 Lempel-Ziv 算法(LZ77)及 32 位循环冗余 校验(Cyclic Redundancy Check,通称 CRC)。

compress:由 UNIX 文件压缩程序 compress 生成的编码格式,采用 Lempel-Ziv-Welch 算法(LZW)。

deflate:组合使用 zlib 格式(RFC1950)及由 deflate 压缩算法(RFC1951)生成的编码格式。

identity:不执行压缩或不会变化的默认编码格式。

注意也可以使用q=?表示权重值,含义和Accept的效果一致,最后注意使用*号作为通配符。

7.3.4 Accept-Language(Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3)

主要作用是告知服务器用户代理支持的自然语言集以及优先级顺序,支持一次性指定多级语言级。

同样也可以使用q=?表示权重值,按照支持语言排序返回最终支持的语言集即为结果。

7.3.5 Authorization(Authorization: Basic dWVub3NlbjpwYXNzd29yZA==)

和名字一样主要作用是告知服务器的用户认证信息,这个请求首部常常用于接口对接和开发,通常对于没有权限的用户会返回401的返回码,告知没有权限访问服务器。

7.3.6 Expect(Expect: 100-continue)

客户端告知服务器某种期望行为使用,但是如果服务器无法理解客户端回应的时候会返回417摆烂。客户端利用这个字段表明自己的期望。但是HTTP1.1实际上只指明了Expect: 100-continue,表示状态码响应为100的客户端需要指定这个字段。

417 表示期望失败

HTTP/1.1 协议里设计 100 (Continue) HTTP 状态码的的目的是,在客户端发送 Request Message 之前,HTTP/1.1 协议允许客户端先判定服务器是否愿意接受客户端发来的消息主体(基于 Request Headers)。

主要针对的情况是如果客户端要给服务器传递一个的数据包,但是如果服务器无法处理或者拒绝处理,这个字段类似提前做好通知。

这个字段的含义其实是让HTTP1.X 加入了“状态”, 不过这种状态严格意义上不能算作标准,所以HTTP1.X依然是无状态的。

7.3.7 From

表示用户代理的邮件地址。注意有时候电子邮件地址因为代理的关系会被记录在 User-Agent 首部字段。

7.3.8 Host(Host: www.hackr.jp

Host 首部字段在 HTTP/1.1 规范内是唯一一个必须被包含在请求内的首部字段。

表示请求方所处的IP地址和端口号信息。

为什么必须要有Host首部?这和单台服务器分配多个域名的虚拟主机的工作机制有很密切的关联。

7.3.9 If-Match

image.png

这样带If前缀的请求首部字段,都是条件请求,服务器接收到附带条件之后需要判定为真才能执行请求。

image.png

如上图所示只有if-matchEtag值进行匹配的时候,服务器才会接受请求,如果不符合则返回412的响应状态码。另外可以使用星号忽略掉Etag的值,只要有资源就接受。

7.3.10 If-Modified-Since(If-Modified-Since: Thu, 15 Apr 2004 00:00:00 GMT)

如果资源晚于这个字段指定的时间,则希望服务器可以处理资源请求,反之如果资源时间没有过变更则需要返回304的响应。

If-Modified-Since 用于确认代理或客户端拥有的本地资源的有效性

7.3.11 If-None-Match

If-Match刚好相反,只有在Etag值和If-None-Match的值不一样的时候才处理请求,这个方法的作用是在GET和HEAD请求中获取实时信息,类似首部字段 If-Modified-Since

7.3.12 Proxy-Authorization(Proxy-Authorization: Basic dGlwOjkpNLAGfFY5)

通过代理服务器返回过来的质询请求包含了客户端的认证,与客户端以及服务器之间的HTTP认证是类似的。

7.3.13 Range(Range: bytes=5001-10000)

首部Range可以告知服务器资源指定范围,上面的字节包含5001到10000字节的资源内容。

如果可以处理相关请求,则返回 206 Partial Content 的响应,如果不能则正常的返回 200。

206 Partial Content:服务器仅发送资源的一部分。

7.3.14 Referer(Referer: www.hackr.jp/index.htm

首部字段 Referer 会告知服务器请求的原始资源的 URI。

注意原始资源的URL可能包含ID和密码等一些敏感信息,如果写入到Reffer传给其他服务器有可能泄密。

Referer 的正确的拼写应该是 Referrer,原因大概是老美当初设计的时候觉得单词更加难读吧。

7.3.15 TE(TE: gzip, deflate;q=0.5)

表示服务器客户端能够处理响应的编码方式以及优先级,和Accept-Encoding字段类似,但是主要用于传输编码。还可以指定TE: trailers 进行分块传输编码。

7.3.16 User-Agent(User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;)

User-Agent 用于传达浏览器的种类,首部字段会把创建请求浏览器和用户代理信息传给服务器处理。

7.4 响应首部字段

响应首部字段指的是从服务器端向客户端返回响应报文时使用的首部。

image.png

7.4.1 Accept-Ranges(Accept-Ranges: bytes)

当不能处理范围请求时,需要指定Accept-Ranges: none

主要告知客户端服务器能处理的请求范围,比如指定为Byte处理字节。

7.4.2 Age(Age: 600)

表示源服务器多久之前创建了响应,字段值为秒。如果创建响应式缓存服务器,则此时间为Age缓存之后响应再次发起认证到认证完成的时间。而代理服务器则需要加上首部字段 Age

7.4.3 ETag(ETag: "82e22293907ce725faf67773957acd12")

能告知客户端的负载标志,以一种可以将资源作为字符串形式的唯一标识方式。服务器会给给每个资源分配Etag,另外需要注意资源更新需要和Etag一样保持更新。

所以Etag被用来区分URI相同但是语言不同的访问区分不同的访问资源,另外Etag存在强弱之分,强Etag会在资源改动的时候立刻刷新,而弱Etag则在资源改变之后在资源头部加入W/的标识标识资源变更。

7.4.4 Location(Location: www.usagid...)

用于表示响应接收方引导到某个和请求URL位置不同的资源上面。同样会配合3xx Redirction 重定向返回,几乎所有的浏览器收到这个字段会尝试完成资源重定向的行为。

7.4.5 Proxy-Authenticate(Proxy-Authenticate: Basic realm="Usagidesign Auth")

首部字段Proxy-Authenticate 会通过代理服务器要求的认证信息发给客户端,注意和服务器以及客户端之间的HTTP访问认证不同,这是代理服务器和客户端之间的认证。

7.4.6 Retry-After(Retry-After: 120)

此字段表示多久之后可以进行请求重试,配合状态码503使用,或者配合3XX Redirect 一起使用。字段值可以是数字也可以是具体的日期时间,也可以是创建响应之后的秒数。

7.4.7 Server(Server: Apache/2.2.17 (Unix))

告知客户端当前服务器的应用程序信息,可能包含软件版本号信息等。

7.4.8 Vary(Vary: Accept-Language)

表示指定资源请求的时候如果使用Accept-language字段的内容相同则直接从缓存返回响应,否则需要从源服务器仅限返回。

所以这个字段适用于控制缓存,源服务器会给代理服务器传递本地缓存使用方法和调用命令。

如果想要获取缓存则需要和包含Vary字段内容指定的请求才能获取,所以哪怕本次请求和上一次完全相同,请求只要Vary不一致,还是需要从源服务器获取。

7.4.9 WWW-Authenticate(WWW-Authenticate: Basic realm="Usagidesign Auth")

主要用于HTTP 访问认证,告知客户端适用于访问请求指定资源的认证方式,如果返回401响应码,则此字段会一并进行返回。注意案例这里的Basic realm="Usagidesign Auth"用于指明资源受到的保护策略。

401 未授权:客户端访问请求的资源需要授权。响应内容中需要包含www-Authnticate 头信息和询问信息,如果已经存在证书访问还是401说明证书已经不被接受,如果401和前一个身份验证请求相同,并且浏览器进行了至少一次重试,则浏览器应该展示响应包含的实体信息(也就是诊断信息)。



相关文章
|
1月前
|
搜索推荐 安全 网络安全
服务器支持HTTPS的时机和条件
【10月更文挑战第23天】服务器支持HTTPS的时机和条件
19 5
|
2月前
使用Netty实现文件传输的HTTP服务器和客户端
本文通过详细的代码示例,展示了如何使用Netty框架实现一个文件传输的HTTP服务器和客户端,包括服务端的文件处理和客户端的文件请求与接收。
46 1
使用Netty实现文件传输的HTTP服务器和客户端
|
26天前
|
存储 Oracle 关系型数据库
oracle服务器存储过程中调用http
通过配置权限、创建和调用存储过程,您可以在Oracle数据库中使用UTL_HTTP包发起HTTP请求。这使得Oracle存储过程可以与外部HTTP服务进行交互,从而实现更复杂的数据处理和集成。在实际应用中,根据具体需求调整请求类型和错误处理逻辑,以确保系统的稳定性和可靠性。
36 0
|
3月前
HAProxy的高级配置选项-配置haproxy支持https协议及服务器动态上下线
文章介绍了如何配置HAProxy以支持HTTPS协议和实现服务器的动态上下线。
155 8
HAProxy的高级配置选项-配置haproxy支持https协议及服务器动态上下线
|
3月前
|
开发者
HTTP状态码是由网页服务器返回的三位数字响应代码,用于表示请求的处理结果和状态
HTTP状态码是由网页服务器返回的三位数字响应代码,用于表示请求的处理结果和状态
33 1
|
4月前
|
移动开发 网络协议 编译器
实战案例3:C语言实现的HTTP服务器
实战案例3:C语言实现的HTTP服务器
231 0
|
Web App开发 安全 应用服务中间件
|
3月前
|
监控 安全 搜索推荐
设置 HTTPS 协议以确保数据传输的安全性
设置 HTTPS 协议以确保数据传输的安全性
|
2月前
|
安全 网络协议 算法
HTTPS网络通信协议揭秘:WEB网站安全的关键技术
HTTPS网络通信协议揭秘:WEB网站安全的关键技术
175 4
HTTPS网络通信协议揭秘:WEB网站安全的关键技术

热门文章

最新文章