RFC2616-HTTP1.1-Header Field Definitions(头字段规定部分—译文) (8)

  接收包含Connection头字段的HTTP/1.0(或较低版本)消息的系统,对于该字段中的每个连接令牌(coonection-token),必须从与连接令牌同名的消息中删除和忽略任何头字段。这可以防止这些头字段被http /1.1代理错误转发。(详情见小节)

14.11 Content-Encoding

  Content-Encoding实体头字段被用来当作media-type的调节器。当存在时,它的值指示哪些附加的内容编码已经应用到实体主体,因此我们要知道在Content-Type头字段中使用的media-type需要使用怎么样的解码机制。Content-Type主要用于允许文档被压缩而不丢失其底层媒体类型的特征。

       Content-Encoding  = "Content-Encoding" ":" 1#content-coding

  内容编码在中被定义。一个使用的例子:

       Content-Encoding: gzip

  内容编码是由请求URI标识的实体的特性。典型地,实体用这样的编码方式存储,并且只有在渲染内容或类似的情况下使用之前才被解码。然而,除非消息中存在“no-transform”缓存控制指令,否则,如果已知接收方可以接受新编码,则非透明代理可以修改内容编码。

  如果一个实体的内容编码不是“identity”,然后,响应必须包含内容编码实体头(节),其中列出了使用的非标识内容编码。

  如果原始服务器无法接受请求消息中实体的内容编码,则服务器应以状态码415(Unsupported Media Type)进行响应。

  如果多个编码被应用到一个实体中,内容编码必须按照应用它们的顺序列出。有关编码参数的其他信息可以由本规范未定义的其他实体头字段提供。

14.12 Content-Language

  Content-Language 实体头字段描述了封闭实体的预期受众的自然语言。注意,这可能不等于实体主体(entity-body)中使用的所有语言。

         Content-Language  = "Content-Language" ":" 1#language-tag

  语言标识在 节中做了定义。内容语言的主要目的是允许用户根据自己的首选语言识别和区分实体。因此,如果正文内容仅针对具有丹麦语文化的读者,则适当的范围是

         Content-Language: da

  如果没有指定内容语言,默认情况下内容是针对所有语言受众的。这可能意味着发送方不认为它是特定于任何自然语言的,或者发送方不知道它是针对哪种语言的。

  可以为多个受众列出多个语言的内容。例如,同时在原始毛利语和英语版本中出现的《瓦伊坦吉条约》的译本就需要

         Content-Language: mi, en

  然而,仅仅因为多个语言存在于一个实体中并不意味着它是针对多个语言受众的。举个例子,初学者的语言入门,比如“拉丁语第一课”,很明显是用来让有英语基础的观众使用的。在这种情况下,内容语言将只包括“EN”。

  Content-Language可以应用于任何媒体类型——它不限于文本文档。

14.13 Content-Length

  Content-Length实体头字段表示实体内容的大小,发送给接收者的是一个十进制八位字节的数字,在HEAD方法中,如果请求是GET,那么将发送的实体主体的大小。

         Content-Length    = "Content-Length" ":" 1*DIGIT

  下面是一个例子

         Content-Length: 3495

  应用程序应该使用此字段来指示消息体的传输长度(transfer-length),除非第节中的规则禁止这一点。

  任何大于或等于0的内容长度都是一个有效值。第4.4节描述了如果没有提供内容长度,如何确定消息体的长度。

  注意,这个字段的含义与MIME中相应的定义有很大的不同,MIME是“消息/外部体”("message/external-body")内容类型中使用的可选字段。在HTTP中,只要消息的长度可以在传输之前确定,就应该发送它,除非第4.4节中的规则禁止这一点。

14.14 Content-Location

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zyxpxz.html