http 部分头字段的注解

包头结构：（http应用层）

 

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */*

      Accept请求标题域用于指示可被接受的回应的介质范围列表。星号"*"用于按范围

将介质类型分组，用"*/*"指示可接受全部介质类型；用"type/*"指示可接受type类型的所有

子类型。对于给定请求的上下文，客户端应当表示出哪些类型是它可以接受的。

 

Accept-Language: zh-cn

可接受语言，Accept-Language请求标题域与Accept相似，但限制了请求回应中首选的自然语言集。

Accept-Encoding: gzip, deflate

可接受编码，Accept-Encoding请求标题域与Accept相似，但是限制了回应中可接受的内容编码（content-coding）值

 

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

用户代理，用户代理请求标题域包含用户原始请求的信息，这可用于统计方面的用途。通过跟踪协议冲突、自动识别用户代理以避免特殊用户代理的局限性，从而做到更好的回应。虽然没有规定，用户代理应当在请求中包括此域。该域可包含多个产品标识（3.7节）及注释以标识该代理及其重要的子产品。按照习惯，产品标识将按子产品对应用的重要性顺序排列。

 

Host: www.baidu.com

主机，指出被请求资源所在的网络主机和端口号，可以通过用户或引用的资源（一般是HTTP URL）指定的原始URI（统一资源标识）来获得。主机字段值必须是由原始URL指定的原始服务器或网关的权威命名。这样可以使原始服务器或网关在内部模糊的URL之间进行区分，比如单一IP下的多主机名服务器的根“/”URL。

（英文读起来比较晦涩，怕翻译产生歧义，原文如下）

The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource (generally an HTTP URL, as described in section 3.2.2). The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on a single IP address.

 

Host = "Host" ":" host [ ":" port ] ; Section 3.2.2

A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP URL). For example, a request on the origin server for   <http://www.w3.org/pub/WWW/> would properly include:

 

       GET /pub/WWW/ HTTP/1.1

       Host: www.w3.org

   A client MUST include a Host header field in all HTTP/1.1 request messages . If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. An HTTP/1.1 proxy MUST ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being requested by the proxy. All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field.

 

Connection: Keep-Alive

Connection 通用头字段允许发送方指定特定的连接所期望的选项，且必须不可以被在更远的连接上的代理传达。

连接头有下面的语法：

       Connection = "Connection" ":" 1#(connection-token)

       connection-token = token

 

http/1.1 代理必须在消息被转发之前解析连接头字段，对于该字段的每个连接符，从消息中删除任何与该连接符同名的字段。连接选项被连接头字段中所提供的连接符告知。而不是被任何附加的头字段，因为假如没有和连接选项相关联的参数，附加头字段将不被发送。在连接头中列出的消息头，必须不能包括端到端头。比如缓冲控制（cache-control）。HTTP/1.1为发送者定义了“close”连接选项来告知在响应完成后，连接将被关闭。例如：

      Connection: close

在请求头或者在响应头里，该字段表明在当前的请求/响应被完成后，连接不应该被认为是持久的。不支持持久连接的HTTP/1.1的应用程序必须在每个消息中包括“close”连接选项。一个系统接收到了一个包含连接头字段的HTTP/1.0（或更低版本）消息，针对这个字段中每个连接符，必须从消息中删除和忽略与连接符同名的头字段。这将保护免于被HTTP/1.1之前的代理错误的转发那样的头字段。

   The Connection general-header field allows the sender to specify options that are desired for that particular connection and MUST NOT be communicated by proxies over further connections.

   The Connection header has the following grammar:

       Connection = "Connection" ":" 1#(connection-token)

       connection-token = token

   HTTP/1.1 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional header field may not be sent if there are no parameters associated with that connection option. Message headers listed in the Connection header MUST NOT include end-to-end headers, such as Cache-Control. HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example,

      Connection: close

 

   in either the request or the response header fields indicates that the connection SHOULD NOT be considered `persistent' (section 8.1) after the current request/response is complete. HTTP/1.1 applications that do not support persistent connections MUST include the "close" connection option in every message. A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header MUST, for each connection-token in this field, remove and ignore any header field(s) from the message with the same name as the connection-token. This protects against mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. See section 19.6.2.

 

Cookie: BAIDUID=C9D9812A8C98611485765CC787FD5431

按照Netscape官方文档中的定义，Cookie是在HTTP协议下，服务器或脚本可以维护客户工作站上信息的一种方式。Cookie是由Web服务器保存在用户浏览器上的小广西文件，它可以包含有关用户的信息（如身份识别号码、密码、用户在Web站点购物的方式或用户访问该站点的次数）。无论何时用户链接到服务器，Web站点都可以访问Cookie信息。

 

要了解Cookie，必不可少地要知道它的工作原理。一般来说，Cookie通过HTTP Headers从服务器端返回到浏览器上。首先，服务器端在响应中利用Set-Cookie header来创建一个Cookie，然后，浏览器在它的请求中通过Cookie header包含这个已经创建的Cookie，并且反它返回至服务器，从而完成浏览器的论证。

Cookie是一种发送到客户浏览器的文本串句柄，并保存在客户机硬盘上，可以用来在某个Web站点会话之间持久地保持数据。Request和Response对象都有一组Cookie。Request.cookie集合是一系列Cookie，从客户端与HTTP Request一起发送到Web服务器。反过来，如果你希望把Cookie发送到客户机，就可以使用Response.cookie
1、ExpiresAbsolute属性
　　该属性可以赋一个日期，过了这个日期Cookie就不能再被使用了。通过给Expires属性赋一个过期的日期，就可以删除Cookie。如：
<%Response.cookies("passtime").expiresAbsolute="1/1/99"%>
2、Domain属性
　　该属性定义Cookie要传送的唯一域。如：Cookie只传送给Microsoft的人，则可以使用以下代码。
<%Response.Cookies("domain").Domain="www.microsoft.com"%>
3、ASP用来写入Cookie即向客户机发送Cookie的语法如下：　　
　　Response.Cookie("Cookie名").[("键名").属性]=内容
　　如果某个ASP文件要创建一个Cookie，则下面的代码可以放在ASP文件的第一个<html>之前，以避免产生错误.
<%Response.Cookies("CookieName")="NewCookie" %>
<html>
......
</html>
4、同样ASP用Request对象的Cookies集合来读取Cookie，如：
<%Response.write Request.Cookies("CookieName")%>
　　下面以一个完整的例子来说明Cookie：
<%
dim Num
Num=Request.Cookies("Visit_num")
if Num>0 then
  Num=Num+1
  Response.write "您已是第" & Num & "次访问本站点了。"
else
  Response.write "欢迎您首次访问本站。"
  Num=1
end if
Response.Cookies("Visit_num")=Num
%>
　　在该例子中，首先读取Cookies变量Visit_num，看用户端计算机是否保存有Cookies变量。如果有该变量，则说明用户已经访问过该页面，同时输入出访问次数。如果用户是首次访问该页面，则其计算机内不会有Cookies变量，程序会显示“欢迎”字样，然后将Cookies变量Visit_num存到用户计算机中，以便该用户下一次访问该页面时给出“访问的次数”信息。
5、Cookie字典
　　有时在一个页面中可能需要定义很多个Cookies变量，为了更好地管理它，在Cookies组件中常引入一人的概念“子键”。引用它的语法如下：
　　Request.Cookies("变更名")("子键名")　　
　　如下面的Cookie创建一个名为"Dictionary"的字典，其中保存了三个键值：
<%
Response.Cookie("info")("Myname")="jeff"
Response.Cookie("info")("Gender")="male"
Response.Cookie("info")("Myheight")="172"
%>
　　事实上客户机上的Cookie字典是以字符串的形式存在：
info=Myname=jeff&Gender=male&Myheight=172
　　如果用户没有指定“子键”名而直接引用Cookies变量，将会返回一个包含所有的“子键”名及值的字符串。例如上面这个例子包含三个“子键”："Myname"、"Gender"和"Myheight"，当用户没有指定其“子键”而直接通过Request.Cookies("info")来引用时，则会得到下列字符串：
info=Myname=jeff&Gender=male&Myheight=172
　　如果要把Cookie中读取的所有数据，可以用下面的代码得到：
<%For each cookie in Request.Cookies
    if Not cookie.HasKeys then
         Response.write cookie & "=" & Request.Cookies(cookie)
     Else
     for each key in Request.Cookies(cookie)
         Response.write cookie&"("&key&")"&"="& Request.Cookies(cookie)(key)
     next
   end if
next
%> 

sCookie

String that specifies or receives the name=value; pairs, plus any of the values listed in Possible Values.

expires=date;

Setting no expiration date on a cookie causes it to expire when the browser closes. If you set an expiration date in the future, the cookie is saved across browser sessions. If you set an expiration date in the past, the cookie is deleted. Use GMT format to specify the date.

domain=domainname;

Setting the domain of the cookie allows pages on a domain made up of more than one server to share cookie information.

path=path;

Setting a path for the cookie allows the current document to share cookie information with other pages within the same domain—that is, if the path is set to /thispathname, all pages in /thispathname and all pages in subfolders of /thispathname can access the same cookie information.

secure;

Setting a cookie as secure; means the stored cookie

 

Referer: http://www.ntop.org/

提交方，提交方请求标题域是出于服务器端利益方面的考虑，允许客户端指明该链接的出处，即该指向资源地址的请求URI是从哪里获得的。这样，服务器将产生一个备份链接（back-links）列表，用于维护受欢迎的资源、登录、缓存优化等活动。

 

Referer           = "Referer" ":" ( absoluteURI | relativeURI )

 

例子：

 

Referer: http://www.w3.org/hypertext/DataSources/Overview.html

 

       如果只给了部分URI，应当参照请求URI来解释它。URI不能包括段（fragment）。

      

       注意：因为链接的原代码可能暴露一些隐私信息，因此强烈建议由用户来决定是否发送

提交人域。例如，浏览器客户端有个选项可以用来进行离线浏览，可以使能或禁止提交人或

表单信息的发送。

 

 

x-flash-version:

flash的版本号

 

pragma:

比如：Pragma: version11-enabled=1

Pragma:no-cache,rate=1.000,stream-time=0,stream-offset=0:0,packet-num=4294967295,max-duration=0

Pragma: packet-pair-experiment=1

Pragma: pipeline-experiment=1

注解,     Prama普通标题域包括一些可能对请求/回应链中的任一接收方有用的特殊指示信息。从协议角度看，所有的注解指示了一些特定的可选行为，事实上，一些系统可能会要求行为与指示一致。

 

Pragma                 = "Pragma" ":" 1#pragma-directive

 

pragma-directive       = "no-cache" | extension-pragma

extension-pragma     = token [ "=" word ]

 

       当"no-cache"出现在请求消息中时，应用程序应当向原始服务器推送此请求，即使它已

经在上次请求时已经缓存了一份拷贝。这样将保证客户端能接收到最权威的回应。它也用来

在客户端发现其缓存中拷贝不可用或过期时，对拷贝进行强制刷新。

       不管注解（Pragma）指示信息对代理（proxy）及网关（gateway）应用程序如何重要，

它必须能穿越这些应用，因为该信息可能对请求/回应链上的其它接收方有用。实际上，如

果注解与某个接收方无关，它应当被该接收方忽略。

Supported:

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中，在实体被传输前，该域就决定

了实体的长度。

 

Content-type:

    内容类型, 内容类型实体标题域指明了发送给接收方的实体主体类型。对于HEAD方法，介质类型已经在前一次GET请求中发出了。

 

Content-Type   = "Content-Type" ":" media-type

介质类型在3.6节中定义，如下例：

 

Content-Type: text/html

 

       更多关于介质类型的讨论在7.2.1节。

3.6 介质类型（Media Types）

 

       HTTP在Content-Type header域（10.5节）中使用Internet介质类型[13]，用以提供开放

的可扩展的数据类型。

media-type             = type "/" subtype *( ";" parameter )

type                      = token

subtype                 = token

 

       参数可参照属性/值对的方式，用类型/子类型的格式来写。

 

Parameter              = attribute "=" value

Attribute                = token

Value                     = token | quoted-string

 

       其中，类型、子类型、参数属性名是大小写敏感的。而参数值不一定是大小写敏感的，

这得看参数名的语法而定。在类型和子类型、属性名和属性值之间不能有LWS（空格）。当

接收到不能识别的介质类型的参数时，用户代理应当忽略它们。

       一些老的HTTP应用不能识别介质类型参数，所以HTTP/1.0的应用程序只能在定义消

息内容时使用介质参数。

       介质参数（Media-type）值用Internet授权分配数字（Internet Assigned Number  

Authority ，IANA [15]）注册。介质类型注册过程请参见RFC1590[13]。不鼓励使用未注册

的介质类型。

 HTTP/1.1 200 OK

Date: Thu, 09 Mar 2006 06:59:37 GMT

      日期普通标题（Date general-header）域表示消息产生的时间，其语法与RFC822中定义

的orig-date是一样的。该域值是HTTP型日期，在3.3节中描述。

 

Date               = "Date" ":" HTTP-date

 

例如：

 

Date: Tue, 15 Nov 1994 08:12:31 GMT

 

       如果直接通过用户代理（如请求）或原始服务器（如回应）的连接接收到消息，日期可

以认为是接收端的当前时间。然而，对于原始服务器来说，时间对其回应缓存的处理非常重

要，所以，原始服务器的回应总是包括日期标题。客户端只有在发送带实体的消息时，才可

向服务器发送日期标题域，比如POST请求。如果接收到的消息被接收方或网关通过有日期

要求的协议缓存起来时，该消息即使没有日期标题域，接收方也会为其分配一个。

 

       理论上，日期应当在实体产生时生成，而实际上，日期可能在消息产生过程的任意时间

生成，而不会造成任何不利的影响。

 

       注意：早期版本错误地将此域值定义为实体主体封装时的日期。这已经被实际应用所更

正。

 

 

Server: Apache/1.3.27

      服务器回应标题域包含由原始服务器用来处理请求的软件信息。该域可包含多个产品标

识（3.7节）及注释以标识服务器及重要的子产品。按照习惯，产品标识将按其应用的重要

顺序排列。

 

Server         = "Server" ":" 1*( product | comment )

 

例如：

 

Server: CERN/3.0 libwww/2.17

 

如果回应要通过代理来推送，代理应用程序不应将它自己的数据加入产品列表。

 

注意：一些指定服务器软件的版本有启示作用，因为这些版本的软件存在一些安全漏洞，

将使服务器更易受到攻击。提倡服务器软件在实现时，将此域变成可以进行配置的选项。

 

       注意：有些服务器不遵守服务器域产品标识的语法约束。

 

 

Cache-Control: max-age=86400

：Cache-Control消息头域说明
Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，响应消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。各个消息中的指令含义如下：

Public指示响应可被任何缓存区缓存。
Private指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息，此响应消息对于其他用户的请求无效。
no-cache指示请求或响应消息不能缓存
no-store用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。
max-age指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。
min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。
max-stale指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。

 

   The Cache-Control general-header field is used to specify directives

   that MUST be obeyed by all caching mechanisms along the

   request/response chain. The directives specify behavior intended to

   prevent caches from adversely interfering with the request or

   response. These directives typically override the default caching

   algorithms. Cache directives are unidirectional in that the presence

   of a directive in a request does not imply that the same directive is

   to be given in the response.

 

      Note that HTTP/1.0 caches might not implement Cache-Control and

      might only implement Pragma: no-cache (see section 14.32).

 

   Cache directives MUST be passed through by a proxy or gateway

   application, regardless of their significance to that application,

   since the directives might be applicable to all recipients along the

   request/response chain. It is not possible to specify a cache-

   directive for a specific cache.

 

    Cache-Control   = "Cache-Control" ":" 1#cache-directive

 

    cache-directive = cache-request-directive

         | cache-response-directive

 

    cache-request-directive =

           "no-cache"                          ; Section 14.9.1

         | "no-store"                          ; Section 14.9.2

         | "max-age" "=" delta-seconds         ; Section 14.9.3, 14.9.4

         | "max-stale" [ "=" delta-seconds ]   ; Section 14.9.3

         | "min-fresh" "=" delta-seconds       ; Section 14.9.3

         | "no-transform"                      ; Section 14.9.5

         | "only-if-cached"                    ; Section 14.9.4

         | cache-extension                     ; Section 14.9.6

 

     cache-response-directive =

           "public"                               ; Section 14.9.1

         | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1

         | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1

         | "no-store"                             ; Section 14.9.2

         | "no-transform"                         ; Section 14.9.5

         | "must-revalidate"                      ; Section 14.9.4

         | "proxy-revalidate"                     ; Section 14.9.4

         | "max-age" "=" delta-seconds            ; Section 14.9.3

         | "s-maxage" "=" delta-seconds           ; Section 14.9.3

         | cache-extension                        ; Section 14.9.6

 

    cache-extension = token [ "=" ( token | quoted-string ) ]

 

   When a directive appears without any 1#field-name parameter, the

   directive applies to the entire request or response. When such a

   directive appears with a 1#field-name parameter, it applies only to

   the named field or fields, and not to the rest of the request or

   response. This mechanism supports extensibility; implementations of

   future versions of the HTTP protocol might apply these directives to

   header fields not defined in HTTP/1.1.

 

   The cache-control directives can be broken down into these general

   categories:

 

      - Restrictions on what are cacheable; these may only be imposed by

        the origin server.

 

      - Restrictions on what may be stored by a cache; these may be

        imposed by either the origin server or the user agent.

 

      - Modifications of the basic expiration mechanism; these may be

        imposed by either the origin server or the user agent.

 

      - Controls over cache revalidation and reload; these may only be

        imposed by a user agent.

 

      - Control over transformation of entities.

 

      - Extensions to the caching system.

 

 

Expires: Fri, 10 Mar 2006 06:59:37 GMT

      过期实体标题域中的日期/时间值指定了实体过期的时间。这为信息提供方提供了使信

息失效的手段。当超过此期限时，应用程序不应再对此实体进行缓存了。过期并不意味着原

始资源会在此期限后发生改变或停止存在。在实际应用中，信息提供者通过检查过期标题域

中所指定的时间，从而获知或预测资源将会发生改变的确切日期。该格式用的是绝对日期时

间（3.2节）。

 

Expires           = "Expires" ":" HTTP-date

 

例如：

 

Expires: Thu, 01 Dec 1994 16:00:00 GMT

 

如果给定日期比日期标题中的要早（或相同），接收方不应缓存附加的实体。如果资源

是动态自然生成的，象有些大量数据的处理，资源的实体应当被加上一个适当的过期时间值。

      

       过期域并不能强制用户代理对其进行刷新或重新载入资源，它只用于缓存机制。当对已

初始化过的资源发出新请求时，该机制才检查该资源的过期状态。

      

       用户代理通常都有历史记录机制，如“后退”按钮和历史记录列表。该种机制可以用来

重新显示某次对话（session）之前已经获取的实体信息。在缺省状态下，过期域不对历史机

制使用。除非用户在配置用户代理时指定了对历史文件进行过期刷新，否则，只要实体还保

存着，历史机制就能显示它，不论该实体是否已经过期。

 

       注意：应用程序应兼容对过期标题非法或错误的实现，如碰到0值或非法的日期格式，

应用程序应将其视为“立即过期（expires immediately）”。虽然这些值不符合HTTP/1.0，对

于一个健壮的应用来说，还是必要的。

 

Last-Modified: Tue, 07 Mar 2006 09:59:00 GMT

 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日期，因为该消息会

导致服务器在未来的某个时间内，用消息原始的日期对该域值进行再次更新。

 

ETag: "350ad3-b51-440d5964"

研究了下etag,看了网上的说明才大致知道这是一个用来标示一个文件的字符串，也是作为断点续传的标准，

 

Etag响应头字段提供了实体标记的当前值。带有实体标记的头被描述在14.24, 14.26 和 14.44部分。实体标记用来和相同资源中的其他实体项比较。（看13.3.3部分）

   The ETag response-header field provides the current value of the entity tag for the requested variant. The headers used with entity tags are described in sections 14.24, 14.26 and 14.44. The entity tag MAY be used for comparison with other entities from the same resource (see section 13.3.3).

 

      ETag = "ETag" ":" entity-tag

 

   Examples:

 

      ETag: "xyzzy"

      ETag: W/"xyzzy"

      ETag: ""

 

Accept-Ranges: bytes

 "Accept-Ranges: bytes0-31",这是什么东东？好像很熟的样子，通过在flashget中一看才知道，原来是断点续传的起始位置和结束位置。

 

Content-Length: 2897

 

内容长度实体头字段指明了实体的长度，以十进制的形式，被发送到接收端，在HEAD方法下，实体尺寸和GET方法下的长度相同。

 

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

 

   例如：

 

       Content-Length: 3495

应用程序应该使用这个字段来表明消息体的传输长度，除非这一项被4.4部分明确禁止。

任何大于或等于0的内容长度均认为是有效值。4.4部分描述了在内容长度给定的情况下怎样决定消息体的长度。

在HTTP中，无论何时，只要消息长度先于发送前被确定，那么这一项就该被发送。除非被特殊规则所禁止。（4.4部分）

   The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.

 

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

   An example is

       Content-Length: 3495

   Applications SHOULD use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in section 4.4.

   Any Content-Length greater than or equal to zero is a valid value. Section 4.4 describes how to determine the length of a message-body if a Content-Length is not given. Note that the meaning of this field is significantly different from the corresponding definition in MIME, where it is an optional field used within the "message/external-body" content-type. In HTTP, it SHOULD be sent whenever the message's length can be determined prior to being transferred, unless this is prohibited by the rules in section 4.4.

 

Connection: close

 

连接普通头字段允许发送房制定特定连接所期望的选项。并且一定不可以被代理或更远的连接传输。连接头有下面的语法：

      Connection = "Connection" ":" 1#(connection-token)

       connection-token = token

HTTP/1.1 代理必须在消息被转发之前解析连接头字段，对于该字段的每个连接符，从消息中删除任何与该连接符同名的字段。连接选项被连接头字段中所提供的连接符告知。而不是被任何附加的头字段，因为假如没有和连接选项相关联的参数，附加头字段将不被发送。在连接头中列出的消息头，必须不能包括端到端头。比如缓冲控制（cache-control）。HTTP/1.1为发送者定义了“close”连接选项来告知在响应完成后，连接将被关闭。例如：

      Connection: close

在请求头或者在响应头里，该字段表明在当前的请求/响应被完成后，连接不应该被认为是持久的。不支持持久连接的HTTP/1.1的应用程序必须在每个消息中包括“close”连接选项。一个系统接收到了一个包含连接头字段的HTTP/1.0（或更低版本）消息，针对这个字段中每个连接符，必须从消息中删除和忽略与连接符同名的头字段。这将保护免于被HTTP/1.1之前的代理错误的转发那样的头字段。

 

   The Connection general-header field allows the sender to specify options that are desired for that particular connection and MUST NOT be communicated by proxies over further connections.

  The Connection header has the following grammar:

      Connection = "Connection" ":" 1#(connection-token)

       connection-token = token

 

   HTTP/1.1 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional header field may not be sent if there are no parameters associated with that connection option.

 

   Message headers listed in the Connection header MUST NOT include end-to-end headers, such as Cache-Control.

 HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example,

       Connection: close

   in either the request or the response header fields indicates that the connection SHOULD NOT be considered `persistent' (section 8.1) after the current request/response is complete.

   HTTP/1.1 applications that do not support persistent connections MUST include the "close" connection option in every message.

   A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header MUST, for each connection-token in this field, remove and ignore any header field(s) from the message with the same name as the connection-token. This protects against mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. See section 19.6.2.

 

 

Content-Type: text/html

实体头的内容类型字段表示发送到接收端的实体的媒体类型，在HEAD方法下，与在GET方法下发送的内容一致。

       Content-Type   = "Content-Type" ":" media-type

媒体类型被定义在3.7部分。一个字段样例是：

      Content-Type: text/html; charset=ISO-8859-4

标识实体媒体类型的方法的更深入讨论，请参考7.2.1部分。

   The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET.

 

       Content-Type   = "Content-Type" ":" media-type

 

   Media types are defined in section 3.7. An example of the field is

      Content-Type: text/html; charset=ISO-8859-4

 

   Further discussion of methods for identifying the media type of an entity is provided in section 7.2.1.

 

Via: 1.1 CNC_BJ_2_411

 

Via普通头字段必须被网关和代理使用来指明媒介协议，和在用户代理与服务器之间请求的接收，和在原始服务器和客户机之间响应的接收。他与RFC822的接收（Received）字段相类似，被企图用于跟踪消息的转发，避免消息的循环，以及标识伴随请求/响应链的所有发送方的协议能力。

   The Via general-header field MUST be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of RFC 822 [9] and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request/response chain.

 

      Via = "Via" ":" 1#( received-protocol received-by [ comment ] )

      received-protocol = [ protocol-name "/" ] protocol-version

      protocol-name     = token

      protocol-version = token

      received-by       = ( host [ ":" port ] ) | pseudonym

      pseudonym         = token

 

   The received-protocol indicates the protocol version of the message received by the server or client along each segment of the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded so that information about the protocol capabilities of upstream applications remains visible to all recipients.

 The protocol-name is optional if and only if it would be "HTTP". The received-by field is normally the host and optional port number of a recipient server or client that subsequently forwarded the message.

   However, if the real host is considered to be sensitive information, it MAY be replaced by a pseudonym. If the port is not given, it MAY be assumed to be the default port of the received-protocol.

   Multiple Via field values represents each proxy or gateway that has forwarded the message. Each recipient MUST append its information such that the end result is ordered according to the sequence of forwarding applications.

   Comments MAY be used in the Via header field to identify the software of the recipient proxy or gateway, analogous to the User-Agent and Server header fields. However, all comments in the Via field are optional and MAY be removed by any recipient prior to forwarding the message. For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses HTTP/1.1 to forward the request to a public proxy at nowhere.com, which completes the request by forwarding it to the origin server at www.ics.uci.edu. The request received by www.ics.uci.edu would then have the following Via header field:

 

       Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

 

   Proxies and gateways used as a portal through a network firewall SHOULD NOT, by default, forward the names and ports of hosts within the firewall region. This information SHOULD only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall SHOULD be replaced by an appropriate pseudonym for that host.

For organizations that have strong privacy requirements for hiding internal structures, a proxy MAY combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry. For example,

 

       Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

 

        could be collapsed to

 

       Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

 

   Applications SHOULD NOT combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced by pseudonyms. Applications MUST NOT combine entries which have different received-protocol values.

 

Age: 5787

 

响应头的年龄“Age”字段传达了发送方的时间估计值，该值是从原始服务器产生响应（或再生）以来的时间值估计。假如它的年龄没有超过它的保鲜期，那么这个被缓存的响应就是“新鲜的”。年龄值是通过13.2.3介绍的方发计算的。

           Age = "Age" ":" age-value

           age-value = delta-seconds

年龄值是非负的十进制整数，用秒代表时间。

假如一个缓存收到了他所能代表的最大正整数，或者假如它的一些年龄计算上溢，它必须把年龄头值转换为2147483648。包含缓存的一个HTTP/1.1服务器必须包括一个年龄头字段，该字段包括在由从服务器自身的缓存中产生的响应消息里。缓存应该使用至少31位范围的算法类型。

 

      The Age response-header field conveys the sender's estimate of the amount of time since the response (or its revalidation) was generated at the origin server. A cached response is "fresh" if    its age does not exceed its freshness lifetime. Age values are calculated as specified in section 13.2.3.

 

           Age = "Age" ":" age-value

           age-value = delta-seconds

 

Age values are non-negative decimal integers, representing time in seconds.

If a cache receives a value larger than the largest positive integer it can represent, or if any of its age calculations overflows, it MUST transmit an Age header with a value of 2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST include an Age header field in every response generated from its own cache. Caches SHOULD use an arithmetic type of at least 31 bits of range.

 

X-Powered-By: ASP.NET

所以可以初步下这样的结论，就是凡头信息里返回有X-Powered-By的，应该都是动态的网页。