这篇文章主要讲解HTTP头部字段相关,参考的资料是RFC7230-7234,主要涉及一般请求头、一般响应头、大文件传输、缓存控制、代理和缓存代理。此外,由于手机客户端比较少用到Cookie和认证(Authentication),这就不讲解了。
一般请求头
请求头是为了提供更多关于请求上下文相关信息,基于目标资源状态进行条件请求,提出想要的响应格式,应用认证或者修改预期的请求处理。一般可以分为控制、条件请求(大文件传输)、内容协商、认证(不讲)和请求上下文。
控制
- Expect,固定值是 “100-continue” 。客户端只发出不包含实体的请求,待服务器返回 “100-continue” 后,客户端才会继续发出包含实体的请求。可能的用法是:客户端发出一个大文件前,先通过这个控制来询问服务器是否接收这个大文件,如果服务器接收则正常处理;否则,服务器拒绝接收,这种情况则免掉了一般直接请求时直接发送大文件,但服务器拒绝服务造成的带宽浪费。
- Max-Forwards,为TRACE和OPTION请求方法提供了一种机制,限制了代理转发请求的次数。
- Host,就是本次请求的主机名,HTTP/1.1唯一不可缺少的头字段。
- TE,用来指定用户代理希望使用的传输编码类型。
- 除此之外,还有 Cache-Control, Pragma, Range, 在后面再说。
内容协商
主要用于协商实体数据类型、传输编码类型、语言类型和字符集等各种内容。
实体数据类型
- Accept,标记的是接收方可理解的 MIME type,可以用“,”做分隔符列出多个类型,让接收方有更多的选择余地
- Content-Type,发送方会在响应报文里用该字段告诉实体数据的真实类型,如
Accept: text/html,application/xml,image/webp,image/png
Content-Type: text/html
传输编码类型
- Accept-Encoding,标记的是接收方支持的压缩格式,例如 gzip、deflate 等,同样也可以用“,”列出多个
- Content-Encoding,发送方实际选择的压缩格式。
- 不过这两个字段是可以省略的,如果请求报文里没有 Accept-Encoding 字段,就表示接收方不支持压缩数据;如果响应报文里没有 Content-Encoding 字段,就表示响应数据没有被压缩。如
Accept-Encoding: gzip, deflate, br
Content-Encoding: gzip
语言类型
人类使用的自然语言,例如英语、汉语、日语等,而这些自然语言可能还有下属的地区性方言,所以在需要明确区分的时候也要使用“type-subtype”的形式,不过这里的格式与数据类型不同,分隔符不是“/”,而是“-”。如:en 表示任意的英语,en-US 表示美式英语,en-GB 表示英式英语,而 zh-CN 就表示我们最常使用的汉语。
- Accept-Language,标记了接收方可理解的自然语言,也允许用“,”做分隔符列出多个类型
- Content-Language,发送方在响应报文里用该字段告诉客户端实体数据使用的实际语言类型,如
Accept-Language: zh-CN, zh, en
Content-Language: zh-CN
字符集
用字符编码来处理文字的方式,现在UTF-8是互联网上的标准字符集。
- 字符集在 HTTP 里使用的请求头字段是Accept-Charset,但响应头里却没有对应的 Content-Charset,而是在Content-Type字段的数据类型后面用“charset=xxx”来表示,这点需要特别注意。如
Accept-Charset: gbk, utf-8
Content-Type: text/html; charset=utf-8
内容协商的质量值
在 HTTP 协议里用 Accept、Accept-Encoding、Accept-Language 等请求头字段进行内容协商的时候,还可以用一种特殊的“q”参数表示权重来设定优先级,这里的“q”是“quality factor”的意思。
权重的最大值是 1,最小值是 0.01,默认值是 1,如果值是 0 就表示拒绝。具体的形式是在数据类型或语言代码后面加一个“;”,然后是“q=value”。
这里要提醒的是“;”的用法,在大多数编程语言里“;”的断句语气要强于“,”,而在 HTTP 的内容协商里却恰好反了过来,“;”的意义是小于“,”的。 如下,它表示浏览器最希望使用的是 HTML 文件,权重是 1,其次是 XML 文件,权重是 0.9,最后是任意数据类型,权重是 0.8。