本篇重点介绍一下HTTP常用的Header
HTTP Header非常之多,很少有人能完全分清这些Header到底是干什么的。鉴于RFC文件规范艰深晦涩难懂,本文对协议规范中列出的HTTP Header进行了梳理,用通俗的语言进行表达,便于读者吃透HTTP协议。
表示客户端期望服务器返回的媒体格式。客户端期望的资源类型服务器可能没有,所以客户端会期望多种类型,并且设置优先级,服务器根据优先级寻找相应的资源返回给客户端。
1 # 注意:先逗号分割类型,再分号分割属性
2 Accept: audio/*; q=0.2, audio/basic
表示audio/basic类型的资源优先,如果没有,就随便其它什么格式的audio资源都可以。q的取值范围是(0-1],其具体值并没有意义,它仅用来排序优先级,如果没有q,默认q=1,也就是最高优先级。
表示客户端期望服务器返回的内容的编码格式。它同Accept头一样,也可以指定多个编码,以q值代表优先级。
1 # 注意:先逗号分割类型,再分号分割属性
2 Accept-Charset: utf8, gbk; q=0.6
表示utf8编码优先,如果不行,就拿gbk编码返回.
Content-Type是服务器向客户端发送的头,代表内容的媒体类型和编码格式,是对Accept头和Accept-Charset头的统一应答。
1 Content-Type: text/html; charset=utf8
表示返回的Body是个html文本,编码为utf8
表示客户端期望服务器返回的内容的语言。很多大型互联网公司是全球化的,它的技术文档一般有有多种语言,通过这个字段可以实现文档的本地化,对国内用户呈现简体中文文档,对英语系用户呈现英文文档。
Accept-Language:zh-CN,en-US;q=0.8,zh-TW;q=0.6
表示大陆简体中文优先,其次英语,再其次中国台湾繁体中文
这个头字段内容是对Accept-Language的应答。服务器通过此字段告知客户端返回的Body信息的语言是什么。
表示传输的请求/响应的Body的长度。GET请求因为没有Body,所以不需要这个头。携带Body的并且可以提前知道Body长度的请求/响应必须带上这个字段,以便对方可以方便的分辨出报文的边界,也就是Body数据何时结束。如果Body太大,需要边计算边传输,不到最后计算结束是无法知道整个Body大小的,这个时候可以使用http分块传输,这个时候也是不需要Content-Length字段的。
当客户端请求的资源在服务器有多个地址时,服务器可以通过Content-Location字段告知客户端其它的可选地址。这个字段比较少见。
在Header中提供这个信息是用来做Body内容校验。它表示Body信息被md5算法处理后的base64字符串。这个字段也比较少见。因为校验机制在TCP层已经有实现了,再来一层校验并没有多大意义。另外资源的md5值往往用来放在后面的ETag头信息中作为资源的唯一标识来使用。