7. 实体（Entity）
完整请求和完整回应消息可能会传输请求或回应中的实体。实体由实体标题
（Entity-Header）域、（通常还有）实体主体（Entity-Body）组成。从这种角度看，客户端
与服务器都将扮演发送方及接收方的角色。某一时刻的角色定位则取决于在这个时刻谁在发
送实体，而谁又在接收实体。
7.1 实体标题域（Entity Header Fields）
实体标题域中定义了一些可选的元信息，如有无实体、请求资源。
Entity-Header = Allow ; Section 10.1
| Content-Encoding ; Section 10.3
| Content-Length ; Section 10.4
| Content-Type ; Section 10.5
| Expires ; Section 10.7
| Last-Modified ; Section 10.10
| extension-header
extension-header = HTTP-header
扩展标题（extension-header）机制允许在不改变协议的前提下定义附加的实体标题域，
但是不能假定接收方可以识别这些域。对于不可识别的标题域，接收方一般是忽略不管，而
代理则继续将其向前推送。
7.2 实体主体（Entity Body）
与HTTP请求或回应一起发送的实体主体的格式和编码信息都在实体标题域
（Entity-Header）中定义。
Entity-Body = *OCTET
实体主体只在请求方法有要求时才会被放在请求消息中。请求消息标题域处的内容长度
标题域（Content-Length header field）的标志将指明请求中的实体主体是否存在。包含实体
主体的HTTP/1.0请求必须包含合法的内容长度标题域。
对回应消息来说，消息中是否包含实体主体取决于请求方法和回应代码。所有的HEAD
请求方法的回应都不应包括主体，即便是实体标题域中指明有主体也一样。在主体中不应包
括这些回应信息，全部1xx（信息）、204（无内容）和304（未修改）。而其它的回应必须包
括实体主体或其内容长度标题（Content-Length header）域的定义值为0。
7.2.1 类型（Type）
当消息中包括实体主体，主体的数据类型由标题域中的内容类型（Content-Type）和内
容编码（Content-Encoding）决定。定义了二层顺序编码模式：
entity-body := Content-Encoding( Content-Type( data ) )
内容类型（Content-Type）指定了下列数据的介质类型（media type）。内容编码
（Content-Encoding）可用于指示附加内容解码方式，通常用于有数据压缩属性的被请求资
源。内容编码的缺省值是none。
任何包括实体主体的消息必须含有内容类型（Content-Type）标题域，以定义主体的类
型。只有当内容类型标题域中没有给出介质类型时，如简单回应消息，接收方可能对该URL
所指定的资源进行判断，如其内容及扩展名等等，从而猜测出该主体的介质类型。如果还无
法确定介质类型，接收方应当将其视为" application/octet-stream"型。
7.2.2 长度（Length）
当实体主体被包括在消息中，主体长度可以有两种方式确定。如果内容长度
（Content-Length）标题域存在，其字节值就是实体主体长度；否则，其主体长度由服务端
关闭连接时确定。
由于服务端无法在连接关闭时发送回应信息，所以不能用关闭连接来指示请求主体的结
束。因而，HTTP/1.0请求如果包含主体，就必须在内容长度（Content-Length）标题域中给
出合法的值。如果请求包括实体主体，且内容长度没指定，服务端将无法识别或无法从其它
域中计算出其主体长度，在这种情况下，服务端将会返回400（非法请求）回应。
注意：一些老的服务器在发送包含由服务器端动态插入的数据流文件时，支持非法的内
容长度使用。要强调的是，未来版本的HTTP协议将会很快改变这种情况。除非客户端自己
知道正在从一个支持它的服务器端得到回应，否则不应依赖于内容长度域的正确性。
8. 方法定义（Method Definitions）
通用的HTTP/1.0的方法集将在下面定义，虽然该方法集可以扩展，但并不保证附加的
方法能够被扩展的客户端和服务器端所支持。
8.1 GET
GET方法就是以实体方式得到由请求URI所指定资源的信息。如果请求URI只是一个
数据产生过程，那么最终要在回应实体中返回的是由该处理过程的结果所指向的资源，而不
是返回该处理过程的描述文字，除非那段文字恰好是处理的输出。
如果请求消息包含If-Modified-Since标题域，GET方法的语法就变成“条件GET”，即
“（conditional GET）”。 条件GET方法可以对指定资源进行判断，如果它在If-Modified-Since
标题域（见10.9节）中的指定日期后发生了更新，才启动传输，否则不传输。这种条件GET
允许被缓存的实体在不必经过多次请求或不必要的数据传输就能进行刷新，从而有助于降低
网络负载。
8.2 HEAD
HEAD方法与GET几乎一样，区别在于，HEAD方法不让服务器在回应中返回任何实
体。对HEAD请求的回应部分来说，它的HTTP标题中包含的元信息与通过GET请求所得
到的是相同的。通过使用这种方法，不必传输整个实体主体，就可以得到请求URI所指定
资源的元信息。该方法通常用来测试超链接的合法性、可访问性及最近更新。
与条件GET不同，不存在所谓的“条件HEAD”，即"conditional HEAD"。即使在HEAD
请求中指定If-Modified-Since标题域，它也会被忽略。
8.3 POST
POST方法用来向目的服务器发出请求，要求它接受被附在请求后的实体，并把它当作
请求队列（Request-Line）中请求URI所指定资源的附加新子项。POST被设计成用统一的
方法实现下列功能：
o 对现有资源的注释（Annotation of existing resources）；
o 向电子公告栏、新闻组，邮件列表或类似讨论组发送消息；
o 提交数据块，如将表格（form [3]）的结果提交给数据处理过程；
o 通过附加操作来扩展数据库。
POST方法的实际功能由服务器来决定，而且通常依赖于请求URI。在POST过程中，
实体是URI的从属部分，就好象文件从属于包含它的目录、新闻组文件从属于发出该文件
的新闻组、记录从属于其所在的数据库一样。
成功的POST不需要在原始服务器创建实体，并将其做为资源；也不需要为未来的访问
提供条件。也就是说，POST方法不一定会指向URI指定的资源。在这种情况下，200（成
功）或204（无内容）都是适当的回应状态，取决于实际回应实体中对结果的描述。
如果在原始服务器上创建了资源，回应应是201（已创建），并包含一个实体
（对"text/html"类型最为适合），该实体中记录着对新资源请求的状态描述。
在所有的HTTP/1.0的POST请求中，必须指定合法的内容长度（Content-Length）。如
果HTTP/1.0服务器在接收到请求消息内容时无法确定其长度，就会返回400（非法请求）
代码。
应用程序不能缓存对POST请求的回应，因为做为应用程序来说，它们没有办法知道服
务器在未来的请求中将如何回应。
9. 状态代码定义（Status Code Definitions）
每个状态代码都将在下面描述，包括它们将对应哪个方法、以及回应中需要的全部元信
息。
9.1 消息1xx（Informational 1xx）
该类状态代码用于表示临时回应。临时回应由状态行（Status-Line）及可选标题组成，
由空行终止。HTTP/1.0中没有定义任何1xx的状态代码，所以它们不是对HTTP/1.0请求的
合法回应。实际上，它们主要用于实验用途，这已经超出本文档的范围。
9.2 成功2xx（Successful 2xx）
表示客户端请求被成功接收、理解、接受。
200 OK
请求成功。回应的信息依赖于请求所使用的方法，如下：
GET 要请求的资源已经放在回应的实体中了。
HEAD 没有实体主体，回应中只包括标题信息。
POST 实体（描述或包含操作的结果）。
201 Created
请求完成，结果是创建了新资源。新创建资源的URI可在回应的实体中得到。原
始服务器应在发出该状态代码前创建该资源。如果该操作不能立即完成，服务器必
须在该资源可用时在回应主体中给出提示，否则，服务器端应回应202（可被接受）。
在本文定义的方法，只有POST可以创建资源。
202 Accepted
请求被接受，但处理尚未完成。请求可能不一定会最终完成，有可能被处理过程随
时中断，在这种情况下，没有办法在异步操作中重新发送状态代码。
202回应是没有义务的，这样做的目的是允许服务器不必等到用户代理和服务器间
的连接结束，就可以响应其它过程的请求（象每天运行一次的，基于批处理的过程）。
在某些回应中返回的实体中包括当前请求的状态指示、状态监视器指针或用户对请
求能否实现的评估信息。
204 No Content
服务器端已经实现了请求，但是没有返回新的信息。如果客户是用户代理，则勿需
为此更新自身的文档视图。该回应主要是为了在不影响用户代理激活文档视图的前
提下，进行script语句的输入及其它操作。该回应还可能包括新的、以实体标题形
式表示的元信息，它可被当前用户代理激活视图中的文档所使用。
9.3 重定向（Redirection 3xx）
该类状态码表示用户代理要想完成请求，还需要发出进一步的操作。这些操作只有
当后跟的请求是GET或HEAD时，才可由用户代理来实现，而不用与用户进行交
互。用户代理永远也不要对请求进行5次以上的重定向操作，这样可能导致无限循
环。
300 Multiple Choices
该状态码不被HTTP/1.0的应用程序直接使用，只是做为3xx类型回应的缺省解释。
存在多个可用的被请求资源。
除非是HEAD请求，否则回应的实体中必须包括这些资源的字符列表及位置信息，
由用户或用户代理来决定哪个是最适合的。
如果服务器有首选，它应将对应的URL信息存放在位置域（Location field）处，
用户代理会根据此域的值来实现自动的重定向。
301 Moved Permanently
请求到的资源都会分配一个永久的URL，这样就可以在将来通过该URL来访问此
资源。有编辑链接功能的客户端会尽可能地根据服务器端传回的新链接而自动更新
请求URI。
新的URL必须由回应中的位置域指定。除非是HEAD请求，否则回应的实体主体
（Entity-Body）必须包括对新URL超链接的简要描述。
如果用POST方法发出请求，而接收到301回应状态码。在这种情况下，除非用户
确认，否则用户代理不必自动重定向请求，因为这将导致改变已发出请求的环境。
注意：当在接收到301状态码后而自动重定向POST请求时，一些现存的用户代理
会错误地将其改为GET请求。
302 Moved Temporarily
请求到的资源在一个不同的URL处临时保存。因为重定向有时会被更改，客户端
应继续用请求URI来发出以后的请求。
新的URL必须由回应中的位置域指定。除非是HEAD请求，否则回应的实体主体
（Entity-Body）必须包括对新URL超链接的简要描述。
如果用POST方法发出请求，而接收到302回应状态码。在这种情况下，除非用户
确认，否则用户代理不必自动重定向请求，因为这将导致改变已发出请求的环境。
注意：当在接收到302状态码后而自动重定向POST请求时，一些现存的用户代理
会错误地将其改为GET请求。
304 Not Modified
如果客户端成功执行了条件GET请求，而对应文件自If-Modified-Since域所指定
的日期以来就没有更新过，服务器应当回应此状态码，而不是将实体主体发送给客
户端。回应标题域中只应包括一些相关信息，比如缓存管理器、与实体最近更新
（entity's Last-Modified）日期无关的修改。相关标题域的例子有：日期、服务器、
过期时间。每当304回应中给出的域值发生变化，缓存都应当对缓存的实体进行更
新。
9.4 客户端错误（Client Error ）4xx
4xx类的状态码表示客户端发生错误。如果客户端在收到4xx代码时请求还没有完成，
它应当立即终止向服务器发送数据。除了回应HEAD请求外，不论错误是临时的还是永久
的，服务器端都必须在回应的实体中包含错误状态的解释。这些状态码适用于任何请求方法。
注意：如果客户端正在发送数据，服务器端的TCP实现应当小心，以确保客户端在关
闭输入连接之前收到回应包。如果客户端在关闭后仍旧向服务器发送数据，服务器会给客户
端发送一个复位包，清空客户端尚未处理的输入缓冲区，以终止HTTP应用程序的读取、解
释活动。
400 非法请求（Bad Request）
如果请求的语法不对，服务器将无法理解。客户端在对该请求做出更改之前，不应
再次向服务器重复发送该请求。
401 未授权（Unauthorized）
请求需要用户授权。回应中的WWW-Authenticate标题域（10.16节）应提示用户
以授权方式请求资源。客户端应使用合适的授权标题域（10.2节）来重复该请求。如果
请求中已经包括了授权信任信息，那回应的401表示此授权被拒绝。如果用户代理在多
次尝试之后，回应一样还是返回401状态代码，用户应当察看一下回应的实体，因为在
实体中会包括一些相关的动态信息。HTTP访问授权会在11节中解释。
403 禁止（Forbidden）
服务器理解请求，但是拒绝实现该请求。授权对此没有帮助，客户端应当停止重复
发送此请求。如果不是用HEAD请求方法，而且服务器端愿意公布请求未被实现原因
的前提下，服务器会将拒绝原因写在回应实体中。该状态码一般用于服务器端不想公布
请求被拒绝的细节或没有其它的回应可用。
404 没有找到（Not Found）
服务器没有找到与请求URI相符的资源。404状态码并不指明状况是临时性的还是
永久性的。如果服务器不希望为客户端提供这方面的信息，还回应403（禁止）状态码。
9.5 服务器错误（Server Error ）5xx
回应代码以‘5’开头的状态码表示服务器端发现自己出现错误，不能继续执行请
求。如果客户端在收到5xx状态码时，请求尚未完成，它应当立即停止向服务器发送数
据。除了回应HEAD请求外，服务器应当在其回应实体中包括对错误情况的解释、并
指明是临时性的还永久性的。
这类回应代码没有标题域，可适用于任何请求方法。
500 服务器内部错误（Internal Server Error）
服务器碰到了意外情况，使其无法继续回应请求。
501 未实现（Not Implemented）
服务器无法提供对请求中所要求功能的支持。如果服务器无法识别请求方法就会回
应此状态代码，这意味着不能回应请求所要求的任何资源。
502 非法网关（Bad Gateway）
充当网关或代理的服务器从要发送请求的上游（upstream）服务器收到非法的回应。
503 服务不可用（Service Unavailable）
服务器当前无法处理请求。这一般是由于服务器临时性超载或维护引起的。该状态
码暗示情况是暂时性的，要产生一些延迟。
注意：503状态码并没有暗示服务器在超载时一定要返回此状态码。一些服务器可
能希望在超载时采用简单处理，即断掉连接。
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）该域的值。
10.9 从何时更改（If-Modified-Since）
If-Modified-Since请求标题域和GET方法一起使用，用于处理下面情况：当在该域指定
的日期以来，请求资源没有发生任何变更。这时，服务器将不会下传该资源的拷贝，即，回
应不带任何实体主体，只是304状态码（未修改）。
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
例如：
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
条件GET方法可以请求服务端将在If-Modified-Since标题域中的指定日期后发生变更
的指定资源下传，也就是说，如果资源没发生变化，就不下传了。其算法如下：
a) 如果请求的回应状态不是200（成功）码或它传过来的If-Modified-Since中的
日期不合法，此时按照普通GET来回应。如果日期比服务器的当前时间还要
晚，则是非法时间。
b) 如果资源在If-Modified-Since日期以后有变化，回应也和普通GET一样
c) 如果资源在If-Modified-Since日期以后没变化，服务器端将回应304（未修改）。
注：该日期应是合法的。
这样做的目的是为了以最小的代价，对被缓存信息进行有效更新。
10.10 最近更改（Last-Modified）
Last-Modified实体标题域表示由发送方设定的资源最近修改日期及时间。该域的精确定
义在于接收方如何去解释它：如果接收方已有此资源的拷贝，但此拷贝比Last-Modified域
所指定的要旧，该拷贝就是过期的。
Last-Modified = "Last-Modified" ":" HTTP-date
例如：
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
该标题域的精确含义取决于发送方的执行方式及原始资源的自然状态。对于文件来说，
可能是它在文件系统的last-modified时间。对于包含多个组成部分的实体来说，可能是组成
部分中最新的last-modify时间。对数据库网关来说，可能是记录的last-update时间戳。对于
虚（virtual）对象来说，可能是内部状态的最近改变时间。
原始服务器不应发送比服务器消息产生时间更晚的Last-Modified日期，因为该消息会
导致服务器在未来的某个时间内，用消息原始的日期对该域值进行再次更新。
10.11 位置（Location）
Location回应标题域定义了由请求URI指定的资源的位置。对于3xx（重定向）回应，
位置域必须能帮助服务器找到相应的URL，以实现对资源的重定向。只允许用绝对URL。
Location = "Location" ":" absoluteURI
例如：
Location: http://www.w3.org/hypertext/WWW/NewLocation.html
10.12 注解（Pragma）
Prama普通标题域包括一些可能对请求/回应链中的任一接收方有用的特殊指示信息。
从协议角度看，所有的注解指示了一些特定的可选行为，事实上，一些系统可能会要求行为
与指示一致。
Pragma = "Pragma" ":" 1#pragma-directive
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" word ]
当"no-cache"出现在请求消息中时，应用程序应当向原始服务器推送此请求，即使它已
经在上次请求时已经缓存了一份拷贝。这样将保证客户端能接收到最权威的回应。它也用来
在客户端发现其缓存中拷贝不可用或过期时，对拷贝进行强制刷新。
不管注解（Pragma）指示信息对代理（proxy）及网关（gateway）应用程序如何重要，
它必须能穿越这些应用，因为该信息可能对请求/回应链上的其它接收方有用。实际上，如
果注解与某个接收方无关，它应当被该接收方忽略。
10.13 提交方（Referer）
提交方请求标题域是出于服务器端利益方面的考虑，允许客户端指明该链接的出处，即
该指向资源地址的请求URI是从哪里获得的。这样，服务器将产生一个备份链接（back-links）
列表，用于维护受欢迎的资源、登录、缓存优化等活动。
Referer = "Referer" ":" ( absoluteURI | relativeURI )
例子：
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
如果只给了部分URI，应当参照请求URI来解释它。URI不能包括段（fragment）。
注意：因为链接的原代码可能暴露一些隐私信息，因此强烈建议由用户来决定是否发送
提交人域。例如，浏览器客户端有个选项可以用来进行离线浏览，可以使能或禁止提交人或
表单信息的发送。
10.14 服务器（Server）
服务器回应标题域包含由原始服务器用来处理请求的软件信息。该域可包含多个产品标
识（3.7节）及注释以标识服务器及重要的子产品。按照习惯，产品标识将按其应用的重要
顺序排列。
Server = "Server" ":" 1*( product | comment )
例如：
Server: CERN/3.0 libwww/2.17
如果回应要通过代理来推送，代理应用程序不应将它自己的数据加入产品列表。
注意：一些指定服务器软件的版本有启示作用，因为这些版本的软件存在一些安全漏洞，
将使服务器更易受到攻击。提倡服务器软件在实现时，将此域变成可以进行配置的选项。
注意：有些服务器不遵守服务器域产品标识的语法约束。
10.15 用户代理（User-Agent）
用户代理请求标题域包含用户原始请求的信息，这可用于统计方面的用途。通过跟踪协
议冲突、自动识别用户代理以避免特殊用户代理的局限性，从而做到更好的回应。虽然没有
规定，用户代理应当在请求中包括此域。该域可包含多个产品标识（3.7节）及注释以标识
该代理及其重要的子产品。按照习惯，产品标识将按子产品对应用的重要性顺序排列。
User-Agent = "User-Agent" ":" 1*( product | comment )
例如：
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
注意：现存有些代理应用将它们的产品信息回到了用户代理域中，这种方法不值得提倡，
因为这样做会使机器在解释这些信息时产生混淆。
注意：现在有些客户端不遵守用户代理域中产品标识的语法约束。
10.16 WWW-授权（WWW-Authenticate）
WWW-授权回应标题域必须被包括在401（未授权）回应消息中。该域值由一个以上的
challenge组成，这些challenge可用于指出请求URI的授权方案及参数。
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
HTTP访问授权处理在11节中描述。用户代理在解析WWW-授权域值时要特别注意看
看它是否包含一个以上的待解决问题（challenge）或是否提供了一个以上的WWW-授权标
题域，因为待解决问题（challenge）的内容中可能包含用逗号分隔的授权参数列表。