Server:www121 Server:www120 Server:NWS_SP

 Request URL:http://www.biyao.com/minisite/bzzx
 Request Method:GET
 Status Code:200 OK
 Remote Address:127.0.0.1:51759
 Response Headers
 view source
 Content-Encoding:gzip
 Content-Language:en-US
 Content-Type:text/html;charset=UTF-8
 Date:Wed, 17 Aug 2016 04:05:59 GMT
 Server:www120
 Set-Cookie:uuid=b111a7df-08ca-4704-9780-25581ec7142b; Domain=.biyao.com; Expires=Fri, 10-Aug-2046 04:05:59 GMT; Path=/
 Set-Cookie:uuid=b111a7df-08ca-4704-9780-25581ec7142b; Domain=.biyao.com; Expires=Fri, 10-Aug-2046 04:05:59 GMT; Path=/
 Transfer-Encoding:chunked
 Vary:Accept-Encoding
 Request Headers
 view source
 Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
 Accept-Encoding:gzip, deflate, sdch
 Accept-Language:en-US,en;q=0.8,zh-CN;q=0.6,zh;q=0.4
 Cache-Control:max-age=0
 Cookie:DZVISIT=02A2CC8EC82E7002EA08F07B1D3E7EC6D22F652214213EE05F103F7FAA99E7AD5C46A8900EB8A34E43A149CF9CC3F9E9C888976F3F8AA696885C752F70D3485EB1752D2DA1C96E8EE2E523A0AE962099009DEEC9C8A937C8; JSESSIONID=F2F07FC5DE09FCA936984F1D50C5B0DB; uuid=b111a7df-08ca-4704-9780-25581ec7142b; Hm_lvt_8263bc34c44278c176458d5aca724aed=1471405869; Hm_lpvt_8263bc34c44278c176458d5aca724aed=1471406755
 Host:www.biyao.com
 Proxy-Connection:keep-alive
 Referer:http://www.biyao.com/help/tel.html
 Upgrade-Insecure-Requests:1
 User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

 Request URL:http://www.biyao.com/home/index.html
 Request Method:GET
 Status Code:200 OK
 Remote Address:127.0.0.1:51759
 Response Headers
 view source
 Content-Encoding:gzip
 Content-Type:text/html
 Date:Wed, 17 Aug 2016 04:06:59 GMT
 Etag:W/"57b3da02-7eee"
 Last-Modified:Wed, 17 Aug 2016 03:29:06 GMT
 Server:nginx
 Thanks:Welcome to our wwww!!
 Transfer-Encoding:chunked
 Vary:Accept-Encoding
 Request Headers
 view source
 Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
 Accept-Encoding:gzip, deflate, sdch
 Accept-Language:en-US,en;q=0.8,zh-CN;q=0.6,zh;q=0.4
 Cookie:DZVISIT=02A2CC8EC82E7002EA08F07B1D3E7EC6D22F652214213EE05F103F7FAA99E7AD5C46A8900EB8A34E43A149CF9CC3F9E9C888976F3F8AA696885C752F70D3485EB1752D2DA1C96E8EE2E523A0AE962099009DEEC9C8A937C8; JSESSIONID=F2F07FC5DE09FCA936984F1D50C5B0DB; uuid=b111a7df-08ca-4704-9780-25581ec7142b; Hm_lvt_8263bc34c44278c176458d5aca724aed=1471405869; Hm_lpvt_8263bc34c44278c176458d5aca724aed=1471406759
 Host:www.biyao.com
 Proxy-Connection:keep-alive
 Upgrade-Insecure-Requests:1
 User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

 Request URL:http://www.biyao.com/minisite/sjzx
 Request Method:GET
 Status Code:200 OK
 Remote Address:127.0.0.1:51759
 Response Headers
 view source
 Content-Encoding:gzip
 Content-Language:en-US
 Content-Type:text/html;charset=UTF-8
 Date:Wed, 17 Aug 2016 04:08:09 GMT
 Server:www121
 Set-Cookie:uuid=b111a7df-08ca-4704-9780-25581ec7142b; Domain=.biyao.com; Expires=Fri, 10-Aug-2046 04:08:10 GMT; Path=/
 Set-Cookie:uuid=b111a7df-08ca-4704-9780-25581ec7142b; Domain=.biyao.com; Expires=Fri, 10-Aug-2046 04:08:10 GMT; Path=/
 Set-Cookie:JSESSIONID=34D6928413A453F6AA2C0FF23FDC5E78; Path=/; HttpOnly
 Transfer-Encoding:chunked
 Vary:Accept-Encoding
 Request Headers
 view source
 Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
 Accept-Encoding:gzip, deflate, sdch
 Accept-Language:en-US,en;q=0.8,zh-CN;q=0.6,zh;q=0.4
 Cookie:DZVISIT=02A2CC8EC82E7002EA08F07B1D3E7EC6D22F652214213EE05F103F7FAA99E7AD5C46A8900EB8A34E43A149CF9CC3F9E9C888976F3F8AA696885C752F70D3485EB1752D2DA1C96E8EE2E523A0AE962099009DEEC9C8A937C8; JSESSIONID=F2F07FC5DE09FCA936984F1D50C5B0DB; uuid=b111a7df-08ca-4704-9780-25581ec7142b; Hm_lvt_8263bc34c44278c176458d5aca724aed=1471405869; Hm_lpvt_8263bc34c44278c176458d5aca724aed=1471406820
 Host:www.biyao.com
 Proxy-Connection:keep-alive
 Referer:http://www.biyao.com/home/index.html
 Upgrade-Insecure-Requests:1
 User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
 Name
 sjzx
 1 / 27 requests ❘ 7.4 KB / 596 KB transferred ❘ Finish: 11.86 s ❘ DOMContentLoaded: 1.46 s ❘ Load: 10.91 s

 Console

 Request URL:http://badge.biyao.com/man/index.html?f_upd=fc-27
 Request Method:GET
 Status Code:200 OK
 Remote Address:127.0.0.1:51759
 Response Headers
 view source
 Cache-Control:max-age=600
 Content-Encoding:gzip
 Content-Length:7172
 Content-Type:text/html;charset=utf-8
 Date:Wed, 17 Aug 2016 04:09:44 GMT
 Expires:Wed, 17 Aug 2016 04:19:44 GMT
 Last-Modified:Wed, 17 Aug 2016 02:05:47 GMT
 Server:NWS_SP
 X-Cache-Lookup:Hit From Disktank Gz
 Request Headers
 view source
 Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
 Accept-Encoding:gzip, deflate, sdch
 Accept-Language:en-US,en;q=0.8,zh-CN;q=0.6,zh;q=0.4
 Cookie:DZVISIT=02A2CC8EC82E7002EA08F07B1D3E7EC6D22F652214213EE05F103F7FAA99E7AD5C46A8900EB8A34E43A149CF9CC3F9E9C888976F3F8AA696885C752F70D3485EB1752D2DA1C96E8EE2E523A0AE962099009DEEC9C8A937C8; uuid=b111a7df-08ca-4704-9780-25581ec7142b; Hm_lvt_8263bc34c44278c176458d5aca724aed=1471405869; Hm_lpvt_8263bc34c44278c176458d5aca724aed=1471406891
 Host:badge.biyao.com
 Proxy-Connection:keep-alive
 Referer:http://www.biyao.com/minisite/sjzx
 Upgrade-Insecure-Requests:1
 User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/ETag

ETagHTTP响应头是资源的特定版本的标识符。这可以让缓存更高效，并节省带宽，因为如果内容没有改变，Web服务器不需要发送完整的响应。而如果内容发生了变化，使用ETag有助于防止资源的同时更新相互覆盖（“空中碰撞”）。

如果给定URL中的资源更改，则一定要生成新的Etag值。 因此Etags类似于指纹，也可能被某些服务器用于跟踪。 比较etags能快速确定此资源是否变化，但也可能被跟踪服务器永久存留。

Header type	Response header
Forbidden header name	no

语法

ETag: W/"<etag_value>"
ETag: "<etag_value>"

指令

W/ 可选

'W/'(大小写敏感) 表示使用弱验证器。 弱验证器很容易生成，但不利于比较。 强验证器是比较的理想选择，但很难有效地生成。 相同资源的两个弱Etag值可能语义等同，但不是每个字节都相同。

"<etag_value>"

实体标签唯一地表示所请求的资源。 它们是位于双引号之间的ASCII字符串（如“675af34563dc-tr34”）。 没有明确指定生成ETag值的方法。 通常，使用内容的散列，最后修改时间戳的哈希值，或简单地使用版本号。 例如，MDN使用wiki内容的十六进制数字的哈希值。

示例

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"

避免“空中碰撞”

在ETag和 If-Match 头部的帮助下，您可以检测到"空中碰撞"的编辑冲突。

例如，当编辑MDN时，当前的wiki内容被散列，并在响应中放入Etag：

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4

将更改保存到Wiki页面（发布数据）时，POST请求将包含有ETag值的If-Match头来检查是否为最新版本。

If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

如果哈希值不匹配，则意味着文档已经被编辑，抛出412前提条件失败错误。

缓存未更改的资源

ETag头的另一个典型用例是缓存未更改的资源。 如果用户再次访问给定的URL（设有ETag字段），显示资源过期了且不可用，客户端就发送值为ETag的If-None-Match header字段：

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

服务器将客户端的ETag（作为If-None-Match字段的值一起发送）与其当前版本的资源的ETag进行比较，如果两个值匹配（即资源未更改），服务器将返回不带任何内容的304未修改状态，告诉客户端缓存版本可用（新鲜）。

规范

Specification	Title
RFC 7232, section 2.3: ETag	Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests

https://tools.ietf.org/html/rfc7232#section-2.3

2.3. ETag

   The "ETag" header field in a response provides the current entity-tag
   for the selected representation, as determined at the conclusion of
   handling the request.  An entity-tag is an opaque validator for
   differentiating between multiple representations of the same
   resource, regardless of whether those multiple representations are
   due to resource state changes over time, content negotiation
   resulting in multiple representations being valid at the same time,
   or both.  An entity-tag consists of an opaque quoted string, possibly
   prefixed by a weakness indicator.

     ETag       = entity-tag

     entity-tag = [ weak ] opaque-tag
     weak       = %x57.2F ; "W/", case-sensitive
     opaque-tag = DQUOTE *etagc DQUOTE
     etagc      = %x21 / %x23-7E / obs-text
                ; VCHAR except double quotes, plus obs-text

      Note: Previously, opaque-tag was defined to be a quoted-string
      ([RFC2616], Section 3.11); thus, some recipients might perform
      backslash unescaping.  Servers therefore ought to avoid backslash
      characters in entity tags.

   An entity-tag can be more reliable for validation than a modification
   date in situations where it is inconvenient to store modification
   dates, where the one-second resolution of HTTP date values is not
   sufficient, or where modification dates are not consistently
   maintained.

   Examples:

     ETag: "xyzzy"
     ETag: W/"xyzzy"
     ETag: ""

Fielding & Reschke           Standards Track                    [Page 9]

---

RFC 7232              HTTP/1.1 Conditional Requests            June 2014

   An entity-tag can be either a weak or strong validator, with strong
   being the default.  If an origin server provides an entity-tag for a
   representation and the generation of that entity-tag does not satisfy
   all of the characteristics of a strong validator (Section 2.1), then
   the origin server MUST mark the entity-tag as weak by prefixing its
   opaque value with "W/" (case-sensitive).

2.3.1. Generation

   The principle behind entity-tags is that only the service author
   knows the implementation of a resource well enough to select the most
   accurate and efficient validation mechanism for that resource, and
   that any such mechanism can be mapped to a simple sequence of octets
   for easy comparison.  Since the value is opaque, there is no need for
   the client to be aware of how each entity-tag is constructed.

   For example, a resource that has implementation-specific versioning
   applied to all changes might use an internal revision number, perhaps
   combined with a variance identifier for content negotiation, to
   accurately differentiate between representations.  Other
   implementations might use a collision-resistant hash of
   representation content, a combination of various file attributes, or
   a modification timestamp that has sub-second resolution.

   An origin server SHOULD send an ETag for any selected representation
   for which detection of changes can be reasonably and consistently
   determined, since the entity-tag's use in conditional requests and
   evaluating cache freshness ([RFC7234]) can result in a substantial
   reduction of HTTP network traffic and can be a significant factor in
   improving service scalability and reliability.

2.3.2. Comparison

   There are two entity-tag comparison functions, depending on whether
   or not the comparison context allows the use of weak validators:

   o  Strong comparison: two entity-tags are equivalent if both are not
      weak and their opaque-tags match character-by-character.

   o  Weak comparison: two entity-tags are equivalent if their
      opaque-tags match character-by-character, regardless of either or
      both being tagged as "weak".

Fielding & Reschke           Standards Track                   [Page 10]

---

RFC 7232              HTTP/1.1 Conditional Requests            June 2014

   The example below shows the results for a set of entity-tag pairs and
   both the weak and strong comparison function results:

   +--------+--------+-------------------+-----------------+
   | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
   +--------+--------+-------------------+-----------------+
   | W/"1"  | W/"1"  | no match          | match           |
   | W/"1"  | W/"2"  | no match          | no match        |
   | W/"1"  | "1"    | no match          | match           |
   | "1"    | "1"    | match             | match           |
   +--------+--------+-------------------+-----------------+

2.3.3. Example: Entity-Tags Varying on Content-Negotiated Resources

   Consider a resource that is subject to content negotiation (Section
   3.4 of [RFC7231]), and where the representations sent in response to
   a GET request vary based on the Accept-Encoding request header field
   (Section 5.3.4 of [RFC7231]):

   >> Request:

     GET /index HTTP/1.1
     Host: www.example.com
     Accept-Encoding: gzip

   In this case, the response might or might not use the gzip content
   coding.  If it does not, the response might look like:

   >> Response:

     HTTP/1.1 200 OK
     Date: Fri, 26 Mar 2010 00:05:00 GMT
     ETag: "123-a"
     Content-Length: 70
     Vary: Accept-Encoding
     Content-Type: text/plain

     Hello World!
     Hello World!
     Hello World!
     Hello World!
     Hello World!

Fielding & Reschke           Standards Track                   [Page 11]

---

RFC 7232              HTTP/1.1 Conditional Requests            June 2014

   An alternative representation that does use gzip content coding would
   be:

   >> Response:

     HTTP/1.1 200 OK
     Date: Fri, 26 Mar 2010 00:05:00 GMT
     ETag: "123-b"
     Content-Length: 43
     Vary: Accept-Encoding
     Content-Type: text/plain
     Content-Encoding: gzip

     ...binary data...

      Note: Content codings are a property of the representation data,
      so a strong entity-tag for a content-encoded representation has to
      be distinct from the entity tag of an unencoded representation to
      prevent potential conflicts during cache updates and range
      requests.  In contrast, transfer codings (Section 4 of [RFC7230])
      apply only during message transfer and do not result in distinct
      entity-tags.

2.4. When to Use Entity-Tags and Last-Modified Dates

   In 200 (OK) responses to GET or HEAD, an origin server:

   o  SHOULD send an entity-tag validator unless it is not feasible to
      generate one.

   o  MAY send a weak entity-tag instead of a strong entity-tag, if
      performance considerations support the use of weak entity-tags, or
      if it is unfeasible to send a strong entity-tag.

   o  SHOULD send a Last-Modified value if it is feasible to send one.

   In other words, the preferred behavior for an origin server is to
   send both a strong entity-tag and a Last-Modified value in successful
   responses to a retrieval request.

   A client:

   o  MUST send that entity-tag in any cache validation request (using
      If-Match or If-None-Match) if an entity-tag has been provided by
      the origin server.

Fielding & Reschke           Standards Track                   [Page 12]

---

RFC 7232              HTTP/1.1 Conditional Requests            June 2014

   o  SHOULD send the Last-Modified value in non-subrange cache
      validation requests (using If-Modified-Since) if only a
      Last-Modified value has been provided by the origin server.

   o  MAY send the Last-Modified value in subrange cache validation
      requests (using If-Unmodified-Since) if only a Last-Modified value
      has been provided by an HTTP/1.0 origin server.  The user agent
      SHOULD provide a way to disable this, in case of difficulty.

   o  SHOULD send both validators in cache validation requests if both
      an entity-tag and a Last-Modified value have been provided by the
      origin server.  This allows both HTTP/1.0 and HTTP/1.1 caches to
      respond appropriately.