HTTP 1.1 RFC学习笔记(二)--协议参数

1 HTTP版本 HTTP版本=“HTTP”“/”1*DIGIT“.”1*DIGIT 注意： 1.1 应用程序的HTTP版本比该应用程序至少有条件一致的HTTP版本更高。代理和网关应用程序需要小心，当转发消息的协议版本与该应用程序的不同时。由于协议版本指示发送者的协议能力，因此代理/网关【禁止】发送器版本指示比实际版本高的消息。如果由到更高版本的请求，代理/网关【必须】要么降级请求版本，要么响应错误，或者切换到隧道行为。 1.2 缓存代理【必须】，网关【可以】，且隧道【禁止】升级版本请求到超过其支持的版本。对该请求的代理/网关的响应【必须】与请求有相同的主要版本 1.3 在HTTP版本间转换可以造成修改有版本引入所需或禁止的头部域 2 统一资源标识符 URI被表述为许多名称：WWW地址，统一文档标识符，统一资源标识符，和统一资源定位符，及名称(URN)的最终组合。 414（Request-URI Too Long）：如果URI超过服务器能够处理的长度 2.1 URI的比较 2.1.1 空的或没有给出的端口号与该URI引用的缺省端口号相同 2.1.2 比较主机名【必须】大小写不敏感 2.1.3 比较方案名【必须】大小写不敏感 2.1.4 空绝对路径与绝对路径”/”相同 3 日期/时间 3.1 Sun 06 Nov 1994 08:49:37 GMT 3.2 Sunday ,06-Nov-94 08:49:37 GMT 3.3 Sun Nov 6 08:49:37 1994 3.4 解析日期值的HTTP/1.1客户端和服务器【必须】接受全部三种格式 3.5 HTTP日期是大小写敏感的，而且【禁止】在语法规定包括SP以外包括额外的LWS 4 缺少字符集一些HTTP/1.0软件将Content-Type头部没有正确的字符集参数解析为“接收方应该猜测”的意思，发送方希望避免这种行为【可以】包括字符集参数，即使当字符集是ISO-8859-1时，且当它知道接收方不会混淆的时候也应该这样做。不幸的是，一些老的HTTP/1.0客户端没有正确处理明确的字符集参数，HTTP/1.1接收方【必须】尊重发送方提供的字符集标签，且这些规定“猜测”字符集的用户代理在最初显示文档时【必须】使用Content-Type域中的字符集，如果他们支持该字符集的话，而不是接收方的选项。 5 内容编码 5.1 内容编码主要用来允许文档压缩或者其他不丢失其底层媒体类型特征和信息的有用的转换 5.2 所有的内容编码值大小写不敏感的，HTTP/1.1使用Accept-Encoding和Content-Encoding头部域中的内容编码值 5.3 它将指出需要使用哪种解码机制来恢复编码 5.4 因特网分配数字权威(IANA)扮演内容编码值符号的注册表，该注册表包括如下符号： gzip , compress , deflate ,identity (为了与以前的HTTP实现兼容，应用程序【应该】认为“x-zip”和“x-compress”分别与“gzip”和“compress”相同 6 传输编码 6.1 与内容编码不同，传输编码是消息而非原始实体的属性。传输编码=“chunked”！传输扩展 传输扩展=符号*(“;”参数) 参数=属性“=”值 属性=符号 值=符号||引用字符串 6.2 HTTP/1.1在TE头部域和Transfer-Encoding头部域中使用传输编码值，不管何时传输编码应用到消息主体，传输编码集【必须】包括”chunked”，除非消息止于连接关闭(Whenever a transfer-coding is applied to a message-body, the set of transfer-encodings MUST include "chunked", unless the message is terminated by closing the connection)；当使用”chunked”传输编码时候,它【必须】是最后应用到消息主体上的传输编码。”chunked”传输编码【禁止】多次应用到消息主体上。该规则运行接收方判断传输消息的长度。 6.3 传输编码（transfer-coding）可能会提供编码参数（译注：看传输编码的定义,3.6节），这些编码参数额外的信息可能会被其它实体头域（entity-header）提供，但这并没有在规范里定义。 6.4 许多老的HTTP/1.1应用程序不能理解传输译码（Transfer-Encoding）头域。 6.5 IANA扮演传输编码值符号的注册表。刚开始，注册表包括下面符号：chunked , identity , gzip ,compress , deflate 6.6 501(Unimplemented)：服务器收到的实体主体有它不理解的传输编码。服务器禁止向HTTP/1.0客户端发送传输编码 6.7 Chunked传输编码 Chunked编码修饰消息的主体，为了以一系列的大块传输它，每块都有它自己的大小指示符，接在【可选】的包含实体头部域的尾巴后。这允许动态生成的内容与必要信息一起传输，以便接受者检验他已经接收完全部信息。在进行Chunked编码传输时，在回复消息的头部有transfer-coding并定为Chunked，表示将用Chunked编码传输内容。采用以下方式编码：　　Chunked-Body = *chunk 　　　　　　　　　"0" CRLF 　　　　　　　　　footer 　　　　　　　　　CRLF 　　chunk = chunk-size [ chunk-ext ] CRLF 　　　　　　chunk-data CRLF 　　hex-no-zero = 　　chunk-size = hex-no-zero *HEX 　　chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] ) 　　chunk-ext-name = token 　　chunk-ext-val = token | quoted-string 　　chunk-data = chunk-size(OCTET) 　　footer = *entity-header 　　编码使用若干个Chunk组成，由一个标明长度为0的chunk结束，每个Chunk有两部分组成，第一部分是该Chunk的长度和长度单位（一般不写），第二部分就是指定长度的内容，每个部分用CRLF隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容，是一些没有写的头部内容。 6.8 Trailer常用头域值指明了在以块（chunked）传输编码消息里的尾部（trailer）里用到的头域。 Trailer = "Trailer" ":" 1#field-name 一个http/1.1消息会包含一个Trailer头域，如果它利用了块（chunked）传输编码并且编码里的尾部（trailer）不为空。这样做是为了使接收端知道块（chunked）传输编码响应消息尾部（trailer）有哪些头域。如果具有块传输编码的消息，没有Trailer头域存在，则此消息的尾部（trailer）将不能包括任何头域。3.6.1节展示了块传输编码的尾部（trailer）的利用限制。 Trailer头域中指示的消息头域不能包括下面的头域： .Transfer-Encoding .Content-Length .Trailer 按照RFC26163.6.1,服务器在响应中使用chunked传输编码【禁止】使用任何头部域的尾巴，除非至少满足下面的一条： 6.8.1.1 请求包括TE头部域指出”trailers”在响应的传输编码中可接受 6.8.1.2 服务器是响应的原始服务器，尾巴域完全由可选的元数据组成，且接收方无需接受该元数据就可以使用该数据（有礼貌的接受原始服务），换句话说，原始服务器可以接受这样的可能性，即尾巴域可能在客户端的路径上被悄悄的放弃 6.9 所有的HTTP/1.1应用程序【必须】能够接收和解码”chunked”传输编码，且如果他们不理解时【必须】忽略大块扩展的扩展项 6.10 　　下面给出一个Chunked的解码过程（RFC文档中有）　　length := 0 　　read chunk-size, chunk-ext (if any) and CRLF 　　while (chunk-size > 0) { 　　read chunk-data and CRLF 　　append chunk-data to entity-body 　　length := length + chunk-size 　　read chunk-size and CRLF 　　} 　　read entity-header 　　while (entity-header not empty) { 　　append entity-header to existing header fields 　　read entity-header 　　} 　　Content-Length := length 　　Remove "chunked" from Transfer-Encoding 7 规范化和文本缺省值 7.1 HTTP应用程序【必须】接受CRLF，光CR,和光LF作为描述通过HTTP接受的文本媒体的断行符。如果文本不支持字节13和10作为对应CR,LF的字符集绘制是，如果对应一些多字节字符集的情况，HTTP允许使用该字符集所定义来描绘等价的CR和LF的任何字符序列作为断行符，这种对待断行符的灵活性只应用于实体主体中的文本类型，光CR和LF【禁止】取代HTTP控制结构中的任何CRLF 7.2 通过HTTP接收的媒体”text”类型和subtype定义为有缺省的“ISO-8859-1”字符集值。不在“ISO-8859-1”或其子集的字符集中的数据【必须】标识适当的字符集值 8 Multipart类型 8.1 我们在实际中文件和表单混合提交、多文件上传的需求也很多，MIME提供了一种”multitype”类型—在单个消息主体中封装一个或多个实体，所有的multitype类型共享通用语法，且【必须】包括boundary参数作为媒体类型值的一部分，消息主体自己是协议的元素且因此【必须】在主体各部分间只使用CRLF描述断行符。任何multipart消息的结尾【必须】是空的：HTTP应用【禁止】传输结尾。存在该限制是为了保证multipart消息主体的自定义属性，这里的消息主体“end“由结尾的multipart边界来指出 8.2 HTTP会无区别对待multipart消息主体与任何其他媒体类型，严格作为负载，一种例外是”multipart/byteranges”类型，当出现在206（Partial Content）响应中时候，一些HTTP缓冲机制会按照RFC2616 13.54和14.16节来解释。如果应用程序接收不认识的multipart的subtype，则应用程序【必须】将其视为与“multipart/mixed”相同。”multipart/form-data”类型特别定义用来携带适合post请求方式处理的表单数据。