HTTP请求头

HTTP头的类型

1. general-header
   general header是request、response都可用的, 但是不能用于entity

   －－ Cache-Control 指定请求和响应遵循的缓存机制 no-cache
   －－ Connection 是否需要持久连接  close/keep-alive
   －－ Date 请求或响应发送的日期和时间
   －－ Pragma 用来包含实现特定的指令
   －－ Trailer 指出头域在分块传输编码的尾部存在
   －－ Transfer-Encoding 文件传输编码
   －－ Upgrade
   －－ Via 告知代理客户端响应是通过哪里发送的
   －－ Warning
   

2. request-header
   传递关于request和客户端的附加信息到服务端,不包括请求的实体信息

   －－ Accept 指定客户端能够接收的内容类型 media-type
   －－ Accept-Charset 浏览器可以接受的字符编码集
   －－ Accept-Encoding 指定浏览器可以支持的web服务器返回内容压缩编码类型
   －－ Accept-Language 浏览器可接受的语言
   －－ Authorization 认证信息
   －－ Expect 用于指出客户端要求的特殊服务器行为
   －－ From 发出请求的用户的Email
   －－ Host 指定请求的服务器的域名和端口号
   －－ If-Match 与Etag配合使用
   －－ If-Modified-Since
   －－ If-None-Match
   －－ If-Range
   －－ If-Unmodified-Since
   －－ Max-Forwards 限制信息通过代理和网关传送的时间
   －－ Proxy-Authorization 连接到代理的授权证书
   －－ Range
   －－ Referer 先前网页的地址，当前请求网页紧随其后,即来路
   －－ TE
   －－ User-Agent
   －－ Cookie
   

3. response-header
   传递关于response和服务端的附加信息

   －－ Accept-Ranges 这个字段说明Web服务器是否支持Range（是否支持断点续传功能）
   －－ Age 从原始服务器到代理缓存形成的估算时间（以秒计，非负）
   －－ ETag 请求变量的实体标签的当前值
   －－ Location  用来重定向接收方到非请求URL的位置来完成请求或标识新的资源
   －－ Proxy-Authenticate 代理服务器响应浏览器,要求其提供代理身份验证信息
   －－ Retry-After 如果实体暂时不可取，通知客户端在指定时间之后再次尝试
   －－ Server web服务器软件名称
   －－ Vary 告诉下游代理是使用缓存响应还是从原始服务器请求
   －－ WWW-Authenticate 表明客户端请求实体应该使用的授权方案
   －－ refresh 应用于重定向或一个新的资源定时刷新
   －－ Set-Cookie
   

4. entity-header
   定义关于entity-body的metainformation(标题字段数据),如果当前没有body, 则定义被request确定的资源信息

   －－ Allow 列出URI对应的资源支持的访问方法,出现在405响应中.例如Allow: GET,HEAD,PUT
   －－ Content-Encoding 内容编码方式,对entity-body进行了编码,比如压缩gzip
   －－ Content-Language
   －－ Content-Length entity-body(如果有压缩，则是压缩后的)的大小
   －－ Content-Location 请求资源可替代的备用的另一地址
   －－ Content-MD5 返回资源的MD5校验值
   －－ Content-Range 指定了返回的Web资源的字节范围
   －－ Content-Type entity-body的media-type
   －－ Expires 缓存的失效时间
   －－ Last-Modified 最近修改时间
   

自己不太好理解的几个HEADER

1. Vary:
   通俗点的例子:
   过程：我的浏览器 ---请求---->squid -----请求----->apache
   apache在返回头中返回了一个vary:Accept-encoding,则squid在存储缓存文件时需要将“我的浏览器”发出的请求头信息中的Accept-encoding字段的值（大多情况就是gzip，deflate之类的）作为缓存key的一部分，因此对于不同的Accept-encoding字段值，都需要保存不同的文件
   

2. Expect:
   Expect请求头部域,用于指出客户端要求的特殊服务器行为.若服务器不能理解或者满足Expect域中的任何期望值,则必须返回417(Expectation Failed)状态,或者如果请求有其他问题,返回4xx状态
   如果服务器收到包含Expect头部域的请求且包含一个它不支持的期望值扩展,则必须返回417(Expectation Failed)状态
   Expect域的机制是逐跳进行的,也就是说如果一个代理服务器收到包含不能满足的期望的请求时,必须返回417(Expectation Failed)状态.很多旧的HTTP/1.0和HTTP/1.1应用不支持Expect头部
   Expect:100-Continue握手的目的是为了允许客户端在发送请求内容之前,判断源服务器是否愿意接受请求（基于请求头部）
   Expect:100-Continue握手需谨慎使用，因为遇到不支持HTTP/1.1协议的服务器或者代理时会引起问题。

3. If-Range+Range
   要实现断点续传的功能，通常都需要客户端记录下当前的下载进度，并在需要续传的时候通知服务端本次需要下载的内容片段
   HTTP1.1协议（RFC2616）中定义了断点续传相关的HTTP头Range和Content-Range字段,一个最简单的断点续传实现大概如下:
   1.客户端下载一个1024K的文件，已经下载了其中512K
   2.网络中断，客户端请求续传，因此需要在HTTP头中申明本次需要续传的片段：
   Range:bytes=512000-
   这个头通知服务端从文件的512K位置开始传输文件
   3.服务端收到断点续传请求，从文件的512K位置开始传输，并且在HTTP头中增加：
   Content-Range:bytes 512000-/1024000
   并且此时服务端返回的HTTP状态码应该是206，而不是200。
   但是在实际场景中，会出现一种情况，即在终端发起续传请求时，URL对应的文件内容在服务端已经发生变化，此时续传的数据肯定是错误的。如何解决这个问题了？显然此时我们需要有一个标识文件唯一性的方法。在RFC2616中也有相应的定义，比如实现Last-Modified来标识文件的最后修改时间，这样即可判断出续传文件时是否已经发生过改动。同时RFC2616中还定义有一个ETag的头，可以使用ETag头来放置文件的唯一标识，比如文件的MD5值。
   终端在发起续传请求时应该在HTTP头中申明If-Match 或者If-Modified-Since 字段，帮助服务端判别文件变化。 另外RFC2616中同时定义有一个If-Range头，终端如果在续传是使用If-Range。If-Range中的内容可以为最初收到的ETag头或者是Last-Modfied中的最后修改时候。服务端在收到续传请求时，通过If-Range中的内容进行校验，校验一致时返回206的续传回应，不一致时服务端则返回200回应，回应的内容为新的文件的全部数据
   

4. Trailer
   
5. TE