标签：请求方法 分割 apache 副本 详细说明 结束 mime类型 16px gzip
如果将HTTP对内容的传输比喻成实际生活中一些货物的运输的化。那HTTP报文就相当于是用于运输货物的“箱子”，而实体内容则是我们真正需要运输的“货物”。所以实体也就是被封装在了报文当中。
现实货物运输中，一般箱子上也会有一些描述信息，用于对运输的货物进行描述说明。HTTP报文中也是一样，也会有相应的实体首部，对实体内容进行描述说明，以便我们的接收方能正确处理实体内容。在HTTP/1.1中常用的实体首部如下所示：
Content-Length首部指示出报文中实体主体的字节大小。此处的大小是指内容编码之后的大小。
比如我们传输一份文档，在传输之前我们进行了gzip压缩，最终传输的是这份压缩后的文档，此时，这里的Content-Length的大小是指gzip压缩后的大小，而不是原始文档大小。
a)、正确携带Content-Length首部
同时为了接收端能正确处理实体内容，除非是使用分块编码，其他情况都应该带上Content-Length的值。有了这个值，通过对收到的内容实际长度和该首部的值进行对比，接收端就能正确判断报文是正常结束，还是因为连接断开等其他非正常结束。
b)、要避免给出错误的Content-Length的值
Content-Length的值错误比缺少Content-Length首部带来的影响还要打。缺少该首部是在某些情况会影响到对内容的处理，但是如果值错误，这个时候接收端始终会认为收到的内容有误，无法正确处理内容。
c)、持久连接必须携带Content-Length
持久连接是必须有Content-Length首部。因为持久连接一直处于连接状态，接收端是无法从关闭连接判别报文的结束，就必须通过Content-Length的值来判断报文再哪里结束，下一条报文从哪里开始。
既然Content-Length首部对于正确处理实体内容如此重要，正常情况也需要给出该首部正确的值，但是并不是所有的服务器或者客户端都严格遵循这一规定。实际处理当中，为了正确确定实体内容的长度，我们一般遵循如下几条规则：
现在我们的请求很多时候都会经过一些代理。如果我们中间的代理处于有误，或者转码出现不兼容等问题的时候，就可能会造成我们收到的报文实体是不正确的。这个时候为了接收端能够自己进行验证收到实体是否正确，发送端可以生成一个实体数据的校验和给接收端用于检测报文的完整性。该校验和正常的中间代理是不会对此进行修改的。不过这种方式只能防止非恶意的修改，如果是恶意修改，除了修改报文实体也会同时修改校验和，这个时候接收端是无法判断的。
一般校验和会放入Content-MD5首部进行传输。应该注意的是该校验对是在内容编码之后（如果存在内容编码），传输编码之前（如果存在传输编码）的数据进行计算生成的。所以接收端在收到报文后，需要先进行传输编码的解码，然后对解码后的内容进行验证。
Content-Type首部用于说明实体主体的MIME类型。关于MIME类型，使用的是在IANA中注册标准MIME类型，一般格式为“主类型/子类型”，如：text/html, img/jpeg等。这里就不详细说明了，感兴趣的可以自己搜索下相关资料。
注：该首部说明的是原始实体主体的媒体类型，就算实体经过内容编码，Content-Type首部说明的仍是编码之前的实体主体即原始实体内容的类型。
该首部除了说明实体的MIME类型外，还可以说明实体所使用的字符编码信息，如：
Content-Type: text/html; charset=utf-8
字符的信息，一般是跟在MIME类型后面，用charset进行指定。它说明把实体中的比特转换为文本文件中的字符的方法。
指定的MIMI类型中，有个稍微特殊的类型就是多部分媒体类型。一般我们在提交表格或者将文档内容作为多个片段进行传世的时候会用到。
HTTP 使用 Content-Type:multipart/form-data 或 Content-Type:multipart/mixed 这样的首部以及多部分主体来发送这种请求，举例如下：
Content-Type: multipart/form-data; boundary=[abcdefghijklmnopqrstuvwxyz]
其中boundary用于说明用于分隔各个部分的字符串，如下面的传输内容是一段提交表单内容的示例：
Content-Type: multipart/form-data; boundary=AaB03x --AaB03x Content-Disposition: form-data; name="submit-name" Sally --AaB03x Content-Disposition: form-data; name="files"; filename="essayfile.txt" Content-Type: text/plain ...contents of essayfile.txt... --AaB03x--
同时这种方式还可以进行嵌套的，比如我们在上述传输表单普通文本内容的基础上，增加一个附件的功能（传输一个text文件和一张gif图片），报文示例如下：
Content-Type: multipart/form-data; boundary=AaB03x --AaB03x Content-Disposition: form-data; name="submit-name" Sally --AaB03x Content-Disposition: form-data; name="files" Content-Type: multipart/mixed; boundary=BbC04y --BbC04y Content-Disposition: file; filename="essayfile.txt" Content-Type: text/plain ...contents of essayfile.txt... --BbC04y” Content-Disposition: file; filename="imagefile.gif" Content-Type: image/gif Content-Transfer-Encoding: binary ...contents of imagefile.gif... --BbC04y-- --AaB03x--
可以看到，整个表单的内容使用多部分媒体传输的时候使用--AaB03x--进行分割，在涉及到附件的时候，我们再次使用多部分媒体类型进行传输，这个时候使用--BbC04y--进行内容分割。
除了请求，我们的响应也是可以使用多部分媒体类型的，如果下面的示例，展示了一个对文档不同范围请求产生的响应：
HTTP/1.0 206 Partial content Server: Microsoft-IIS/5.0 Date: Sun, 10 Dec 2000 19:11:20 GMT Content-Location: http://www.joes-hardware.com/gettysburg.txt Content-Type: multipart/x-byteranges; boundary=--[abcdefghijklmnopqrstu vwxyz]-- Last-Modified: Sat, 09 Dec 2000 00:38:47 GMT --[abcdefghijklmnopqrstuvwxyz]-- Content-Type: text/plain Content-Range: bytes 0-174/1441 Fourscore and seven years ago our fathers brought forth on this continent a new nation, conceived in liberty and dedicated to the proposition that all men are created equal. --[abcdefghijklmnopqrstuvwxyz]-- Content-Type: text/plain Content-Range: bytes 552-761/1441 But in a larger sense, we can not dedicate, we can not consecrate, we can not hallow this ground. The brave men, living and dead who struggled here have consecrated it far above our poor power to add or detract. --[abcdefghijklmnopqrstuvwxyz]-- Content-Type: text/plain Content-Range: bytes 1344-1441/1441 and that government of the people, by the people, for the people shall not perish from the earth. --[abcdefghijklmnopqrstuvwxyz]--
很多时候我们在传输内容实体之前，会对实体内容进行编码处理。比如进行gzip压缩，或者是加密等。一般我们称之这个过程为内容编码。
内容编码的主要过程有如下3步：
HTTP定义了一些
这里面gzip是使用比较平凡的一种压缩编码方式。
内容编码一般都是服务器进行编码，客户端收到报文后进行解码。这样，可能存在一种情况是服务器用了一种客户端无法解码的类型进行编码，这个时候就会出现错误。在HTTP中为了解决这种错误，引入了Accept-Encoding首部。客户端在请求的时候，可以使用该首部告知服务器端客户端可以处理的编码类型。同样，如果可以接收处理多个编码类型，我们可以使用“,”隔开每种编码，同时可以为每种编码指定一个优先级，告知服务器，优先选择哪种编码，示例如下：
Accept-Encoding: compress, gzip Accept-Encoding: * Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity;q=0.5, *;q=0
其中"*"代表可以接收任务编码类型，如果客户端请求的时候没有使用Accept-Encoding首部，也即默认可以处理所有编码类型。
客户端可以给每种编码附带Q（质量）值参数来说明编码的优先级。
Q（0.0~1.0）:0.0说明客户端不想接受所说明的编码
1.0则表明最希望使用的编码，
* 表示“任何其他方法”
identity编码代号只能在Accept-Encoding首部中出现，客户端用它来说明相对于其他内容编码算法的优先级
虽然这里的传输编码和前面介绍的内容编码都是用于对实体操作。但是两种编码的目的不太一样，内容编码一般是为了对内容进行压缩和转换等，而传输编码是为了其他一些架构的因素考虑进行使用，同内容的格式无关。同样两种编码对某些首部的影响也不一样，比如实体摘要Content-MD5，一般是用作于内容编码之后，传输编码之前。同样，如果一般代用传输编码后，Content-Length首部的值也通常会做忽略处理。
实际使用当中，一般传输编码主要用于解决报文未知大小和安全性的问题。不过由于安全性现在通常用HTTPS就能很好处理了。所以大多数时候传输编码就是用于解决报文未知大小的问题。比如一些动态生成的报文，如果不能生成完成我们就没法得知报文实体的大小，但是有时候我们又希望在完全生成完成之前就开始传输数据，提高效率。
HTTP协议中提供了Transfer-Encoding和TE两个首部用于控描述和控制传输编码。
传输编码的值都是大小写无关的。
目前HTTP规范中，仅仅定义了一种传输编码——分块编码。
分块编码把报文分割为若干个大小已知的块。块之间是紧挨着发送的，这样就不需要在发送之前知道整个报文的大小了，也就解决了我们上面提到的未知报文大小的问题。
注：分块编码是一种传输编码，因此是报文的属性，而不是主体的属性
在正常情况，如果不是使用的持久连接。那么客户端直接可以一直读取到连接关闭就意味着报文结束了。
但是如果是在持久连接中，如果事先不知道报文实体的大小。这个时候就可以使用分块编码。分块编码允许服务器把主体逐块发送，说明每块的大小就可以了。因为主体是动态创建的，服务器可以缓冲它的一部分，发送其大小和相应的块，然后在主体发送完之前重复这个过程。服务器可以用大小为 0 的块作为“主体结束”的信号，这样就可以继续保持连接，为下一个响应做准备。
如果客户端的 TE 首部中说明它可以接受拖挂的话，服务器就可以在分块的报文最后加上拖挂。不过该选项为可选选项，所以就看你是否需要了。比如我们可以在最后拖挂一个报文整个实体内容的校验和。客户端在接收完全部分块内容后，也可以计算出报文实体的校验和，然后进行对比，以验证报文内容的完整性。
我们在使用传输编码的时候，一定要注意遵守如下规则：
新鲜度
Expires(过期) ：客户端和服务器为了能正确使用Expires首部，他们的时钟必须同步。
Cache-Control|（缓存控制）：首部可以使用秒数来规定文档最长使用期---从文档离开服务器之后算起的总计时间
有条件的请求
仅当资源改变时才请求副本，这种特殊请求称为有条件的请求，有条件的请求是标准的HTTP请求报文
有条件的请求是通过以“If-” 开头的有条件的首部来实现的。
每个有条件的请求都通过特定的验证码来发挥作用，验证码是文档实例的一个特殊属性，用来测试条件是否为真
HTTP两种验证码
Last-Modified 和ETag
HTTP把验证码分为两类：
弱验证码（weak validators）
强验证码（strong validators）
有些时候，我们并不需要请求一个完整的文档内容，可能只需要文档中的某个片段。比如在多线程下载的时候，可能每个线程都只需请求资源的部分内容即可。这个时候就可以利用范围请求来实现。HTTP中，通过Range首部实现范围请求。如下：
GET /bigfile.html HTTP/1.1 Host: www.joes-hardware.com Range: bytes=4000- ……
该示例中，客户端通过Range首部，告诉服务器我只要资源第4000字节以后的内容。这里我们不知道文档总的打下，所以可以通过不指定结尾字节数，告知服务器返回从4000到结尾的部分。如果你知道具体需要的范围，也可以指定具体的区间。
服务器可以通过在响应中包含Accept-Ranges首部的形式向客户端说明可以接受的访问请求
HTTP/1.0 206 Partial content Date：FRI, 05 Nov 1999 22:35:15 GMT Server：Apache/1.2.4 Accept-Ranges ：bytes ...
服务器上的文档并不是一层不变的，如果我们服务器上的文档发生了变化。客户端缓存了变化之前的文档内容，这个时候客户端发起请求的时候。如果把整个文档全部返回给客户端，那是很浪费资源的，特别是有时候改动很小的时候。这个时候如果我们可以只返回有改动（差异）的部分，客户端拿到这部分内容之后，将本地缓存更新后展示给用户即可。这样既节约资源，也能提高传输的速度。这种情况就可以利用差异编码实现。
差异编码是HTTP协议的一个扩展，它通过交换对象改变的部分而不是完整的对象来优化传输性能。
差异编码也是一类实例操控，因为它依赖客户端和服务器之间针对特定的对象实例来交换信息。
差异编码的过程如下图所示：
上图展示了差异编码的结构，包括请求、生成、接收和装配文档的全过程。
A-IM 是 Accept-Instance-Manipulation（接受实例操控）的缩写，用于告诉服务器可以接受差异的类型（算法）。服务器在响应中用IM首部告诉客户端，本次返回的差异数据是用的何种操作类型（算法）。
服务端发送：一个特殊的响应代码-----226 IM Used 告知客户端它正在发送的是所请求对象的实例操控，而不是那个完整的对象本身。
另外这里总结一下，目前在IANA中注册实例操作类型（不仅仅是差异操作类型，还包括前面的一些内容编码的操作）如下表所示：
标签：请求方法 分割 apache 副本 详细说明 结束 mime类型 16px gzip
原文地址：https://www.cnblogs.com/liuzhiyun/p/11517025.html
