HTTP协议(RFC中文版)-10. 标题域定义

falcon_13

       
       
       
       
       
       
10.
标题域定义（Header
Field
Definitions）

本节定义了HTTP/1.0标题域常用的语法及语义。无论是发送方还是接收方，都有
可能做为客户端或服务器端，具体角色取决于在此时刻究竟是谁在接收、谁在发送。
10.1
允许（Allow）
表示由请求URI所指定的资源支持在Allow实体标题域中列出的方法，目的是让接收
方更清楚地知道请求此资源的合法方式。Allow标题域不允许在POST方法中使用，如果非
要这么做，将被忽略。
Allow
= "Allow" ":" 1#method
Example
of use:
      
Allow: GET, HEAD
该域不能防止客户端尝试其它方法。但实际上由Allow标题域中的值所表示的指示
信息是有用的，应当被遵守。实际的Allow方法集在每次向原始服务器上发出请求时定
义。
由于用户代理（user
agent）可能出于其它目的与原始服务器通讯，做为代理（proxy）
来说，即使无法识别请求所指定的所有方法，也不能修改该请求的Allow标题域。
Allow标题域并不表示服务器实现了哪些方法。
10.2
授权（Authorization）
通常，用户代理在收到401（未授权）回应时，可能（也可能不会）希望服务器对其授
权。如果希望授权，用户代理将在请求中加入授权请求标题（Authorization
request-header）
域。授权域值由信任证书组成，其中有对用户代理所请求资源领域的授权信息。
Authorization
= "Authorization" ":" credentials
HTTP访问授权在11节中描述。如果请求中的授权指定了一个范围，那在此范围的其
它请求也都具有相同的信任关系。
对包含授权信息域的请求来说，其回应是不能被缓存的。
10.3
内容编码（Content-Encoding）
内容编码的实体标题域（entity-header）用作介质类型（media-type）的修饰符。它指明
要对资源采用的附加内容译码方式，因而要获得内容类型（Content-Type）标题域中提及的
介质类型，必须采用与译码方式一致的解码机制。内容编码主要用来记录文件的压缩方法。
各种压缩方法将在后面列出。
Content-Encoding
= "Content-Encoding" ":" content-coding
内容译码（Content
codings）在3.5节中定义，例如：
Content-Encoding:
x-gzip
内容编码是请求URI指定资源的一个特性，一般来说，资源用编码方式存储，只有在
通过解码变换以后才能使用。
10.4
内容长度（Content-Length）
内容长度（Content-Length）实体标题域指明了发送到接收方的实体主体（Entity-Body）
长度，用字节方式存储的十进制数字表示。对于HEAD方法，其尺寸已经在前一次GET请
求中发出了。

Content-Length
= "Content-Length" ":" 1*DIGIT
例如：
Content-Length:
3495
不论实体是何种介质类型，应用程序都将通过该域来判定将要传输的实体主体尺寸。所
有包括实体主体的HTTP/1.0的请求消息都必须包括合法的内容长度值。

任何0以上（包括0）的值都是合法的内容长度值。在7.2.2节描述了当内容长度值没
有给出时，如何决定回应实体主体长度的方法。
注意：该域的含义与在MIME中定义的有重要区别。在MIME中，它是可选域，只
在"message/external-body"内容类型中使用；而在HTTP中，在实体被传输前，该域就决定
了实体的长度。
10.5
内容类型（Content-Type）
内容类型实体标题域指明了发送给接收方的实体主体长度。对于HEAD方法，介质类
型已经在前一次GET请求中发出了。
Content-Type  
= "Content-Type" ":" media-type
介质类型在3.6节中定义，如下例：
Content-Type:
text/html
更多关于介质类型的讨论在7.2.1节。
10.6
日期（Date）
日期普通标题（Date
general-header）域表示消息产生的时间，其语法与RFC822中定义
的orig-date是一样的。该域值是HTTP型日期，在3.3节中描述。
Date  
= "Date" ":" HTTP-date
例如：
Date:
Tue, 15 Nov 1994 08:12:31 GMT
如果直接通过用户代理（如请求）或原始服务器（如回应）的连接接收到消息，日期可
以认为是接收端的当前时间。然而，对于原始服务器来说，时间对其回应缓存的处理非常重
要，所以，原始服务器的回应总是包括日期标题。客户端只有在发送带实体的消息时，才可
向服务器发送日期标题域，比如POST请求。如果接收到的消息被接收方或网关通过有日期
要求的协议缓存起来时，该消息即使没有日期标题域，接收方也会为其分配一个。
理论上，日期应当在实体产生时生成，而实际上，日期可能在消息产生过程的任意时间
生成，而不会造成任何不利的影响。
注意：早期版本错误地将此域值定义为实体主体封装时的日期。这已经被实际应用所更
正。
10.7
过期（Expires）

过期实体标题域中的日期/时间值指定了实体过期的时间。这为信息提供方提供了使信
息失效的手段。当超过此期限时，应用程序不应再对此实体进行缓存了。过期并不意味着原
始资源会在此期限后发生改变或停止存在。在实际应用中，信息提供者通过检查过期标题域
中所指定的时间，从而获知或预测资源将会发生改变的确切日期。该格式用的是绝对日期时
间（3.2节）。
Expires
= "Expires" ":" HTTP-date
例如：
Expires:
Thu, 01 Dec 1994 16:00:00 GMT
如果给定日期比日期标题中的要早（或相同），接收方不应缓存附加的实体。如果资源
是动态自然生成的，象有些大量数据的处理，资源的实体应当被加上一个适当的过期时间值。

过期域并不能强制用户代理对其进行刷新或重新载入资源，它只用于缓存机制。当对已
初始化过的资源发出新请求时，该机制才检查该资源的过期状态。

用户代理通常都有历史记录机制，如“后退”按钮和历史记录列表。该种机制可以用来
重新显示某次对话（session）之前已经获取的实体信息。在缺省状态下，过期域不对历史机
制使用。除非用户在配置用户代理时指定了对历史文件进行过期刷新，否则，只要实体还保
存着，历史机制就能显示它，不论该实体是否已经过期。
注意：应用程序应兼容对过期标题非法或错误的实现，如碰到0值或非法的日期格式，
应用程序应将其视为“立即过期（expires
immediately）”。虽然这些值不符合HTTP/1.0，对
于一个健壮的应用来说，还是必要的。
10.8
来自（From）

From请求标题域，如果给出来，则应包括一个使用此用户代理的人类用户的Internet　
e-mail地址。该地址应当能被系统识别，就象RFC822[7]（已经更新为RFC1123[6]）中的邮
箱定义一样。
From
= "From" ":" mailbox
例如：
From:
webmaster@w3.org
该标题域可能用来做为登录目的使用，以确定对某资源的请求是否合法。它不应用于不
安全的访问保护。该域的解释是，请求已按请求人指定的行为方式完成，而该请求人将为此
种方式负责。特殊情况下，机器人（robot）代理也应包括此标题域，域中注明是谁运行它
的，这样，当接收端发生任何问题时，都可以同这个人取得联系。

该域中的Internet
e-mail地址可以与处理该请求的Internet主机分离。例如，当请求通过
代理（proxy）时，应使用原始的传输地址。

注意：客户端在没有得到用户批准时，不应发送From标题域，因为这样做可能会产生
用户隐私及网站安全方面的问题。强烈建议在请求之前提供手段以禁止（disable）、允许
（enable）、修改（modify）该域的值。
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/57427/showart_446009.html