浏览器是否检查 PUSH_PROMISE-frames 内的条件 headers？
Does the Browser check conditional headers inside PUSH_PROMISE-frames?
我知道浏览器可以发送RST_STREAM-frames来取消serverpush。
在PUSH_PROMISE中发送Last-Modified或Etagheaders有意义吗？
或者 to-be-pushed 资源的验证是否仅基于它们的 URI（正如 Simone Bordet 两年前回答以下问题一样）？
我找不到这个问题的确切答案。
当HTTP/2服务器推送资源时，它会生成PUSH_PROMISE帧发送给客户端，同时它会创建一个合成请求，就像远程客户端一样处理已发送。
请记住，PUSH_PROMISE 帧表示客户端为该资源发出的 请求，而不是响应。
通常，PUSH_PROMISE 帧的内容 headers 和合成请求的 headers 是相同的，但是 - 取决于实现 - 情况可能并非如此.
Headers Last-Modified 或 ETag 仅在响应中有意义，因此将它们添加到 PUSH_PROMISE 框架中是没有意义的。
将其他 request headers 如 If-Modified-Since 添加到 PUSH_PROMISE 是否有意义取决于相同的 headers 用于合成请求。
如果使用相同的 headers，通常是这种情况，那么添加 headers 例如 If-Modified-Since 只会影响 server-side 处理：服务器可能会生成 304 Not Modified 在处理合成请求时。
但是，如果服务器为资源发送 PUSH_PROMISE，然后再发送 304，这将很奇怪。如果服务端知道客户端已经缓存了资源，不妨跳过发送PUSH_PROMISE.
将 response headers 如 Last-Modified 添加到 PUSH_PROMISE 框架没有意义，因为 PUSH_PROMISE 表示请求。
添加条件 request headers 例如 If-Modified-Since 通常需要服务器了解以前提供给客户端的资源：它有了解资源是否已被提供，以便向客户端发送 304 以获取推送的资源将使客户端使用其缓存中已存在的资源。
经过更深入的搜索，我想我找到了答案：
pushBuilder's Api 对 .lastModified() 说：
Set the last modified date to be used for conditional pushes.
和.etag()：
Set the etag to be used for conditional pushes.
我误解了那些解释和想法，指定的值被发送到浏览器里面 PUSH_PROMISE 帮助它决定是接受推送文件还是取消流（通过发送 RST_STREAM ).
事实上，这些值似乎告诉服务器，如果它必须推送某事。或不。通过将文件的 last-modified-date 设置为 .lastModified()，我得到了 Simone Bordet 在他上面的评论中描述的行为：发送了 304，即使我的缓存中不存在该文件。
所以现在很清楚，在不知道客户端缓存中到底有什么的情况下设置这些值是没有意义的。
PUSH_PROMISE 中的条件 headers 现在似乎不存在：
我在 HTTP2 规范中没有找到任何相关信息，在阅读 chrome 的 issue-tracker 时，我发现 Tom Bergan 在一个开放的 (02.01.2017) 问题上对此发表评论 (https://bugs.chromium.org/p/chromium/issues/detail?id=232040#c62):
...
I think a better way to handle this case is to convert the pushed response to a 304 when the pushed response matches the cached resource. There are two possible implementations:
Don't cancel the push until after receiving the pushed response headers (since the response headers contain ETag and/or Last-Modified). If the pushed resource is already cached, the browser would convert the pushed response to a 304 and cancel the push. However, IMO, this waits too long to cancel the push.
Add conditional headers like If-Match to the PUSH_PROMISE so the browser knows exactly which resource is being pushed. This is a good idea but it would need to be spec'd out before we could implement it.
https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0522.html
...
所以我期望的可能（通过读取 PUSH_PROMISE 中发送的一些 header-information 来帮助浏览器检查缓存资源的有效性）现在是不可能的，但最终会。
除此之外，似乎 cache-digest 将在未来某个地方在浏览器中实现，这将更加有效，因为可以避免在服务器上进行不必要的推送。 Chrome 已经在着手解决这个问题，如下所示：https://docs.google.com/document/d/1HhmyzKUPuWcCs8wG_GLSu3mvptygXtO2mBl5xlmEB-4/edit#
说的不对请指正
我知道浏览器可以发送RST_STREAM-frames来取消serverpush。
在PUSH_PROMISE中发送Last-Modified或Etagheaders有意义吗？
或者 to-be-pushed 资源的验证是否仅基于它们的 URI（正如 Simone Bordet 两年前回答以下问题一样）？
我找不到这个问题的确切答案。
当HTTP/2服务器推送资源时，它会生成PUSH_PROMISE帧发送给客户端，同时它会创建一个合成请求，就像远程客户端一样处理已发送。
请记住，PUSH_PROMISE 帧表示客户端为该资源发出的 请求，而不是响应。
通常，PUSH_PROMISE 帧的内容 headers 和合成请求的 headers 是相同的，但是 - 取决于实现 - 情况可能并非如此.
Headers Last-Modified 或 ETag 仅在响应中有意义，因此将它们添加到 PUSH_PROMISE 框架中是没有意义的。
将其他 request headers 如 If-Modified-Since 添加到 PUSH_PROMISE 是否有意义取决于相同的 headers 用于合成请求。
如果使用相同的 headers，通常是这种情况，那么添加 headers 例如 If-Modified-Since 只会影响 server-side 处理：服务器可能会生成 304 Not Modified 在处理合成请求时。
但是，如果服务器为资源发送 PUSH_PROMISE，然后再发送 304，这将很奇怪。如果服务端知道客户端已经缓存了资源，不妨跳过发送PUSH_PROMISE.
将 response headers 如 Last-Modified 添加到 PUSH_PROMISE 框架没有意义，因为 PUSH_PROMISE 表示请求。
添加条件 request headers 例如 If-Modified-Since 通常需要服务器了解以前提供给客户端的资源：它有了解资源是否已被提供，以便向客户端发送 304 以获取推送的资源将使客户端使用其缓存中已存在的资源。
经过更深入的搜索，我想我找到了答案：
pushBuilder's Api 对 .lastModified() 说：
Set the last modified date to be used for conditional pushes.
和.etag()：
Set the etag to be used for conditional pushes.
我误解了那些解释和想法，指定的值被发送到浏览器里面 PUSH_PROMISE 帮助它决定是接受推送文件还是取消流（通过发送 RST_STREAM ).
事实上，这些值似乎告诉服务器，如果它必须推送某事。或不。通过将文件的 last-modified-date 设置为 .lastModified()，我得到了 Simone Bordet 在他上面的评论中描述的行为：发送了 304，即使我的缓存中不存在该文件。
所以现在很清楚，在不知道客户端缓存中到底有什么的情况下设置这些值是没有意义的。
PUSH_PROMISE 中的条件 headers 现在似乎不存在：
我在 HTTP2 规范中没有找到任何相关信息，在阅读 chrome 的 issue-tracker 时，我发现 Tom Bergan 在一个开放的 (02.01.2017) 问题上对此发表评论 (https://bugs.chromium.org/p/chromium/issues/detail?id=232040#c62):
... I think a better way to handle this case is to convert the pushed response to a 304 when the pushed response matches the cached resource. There are two possible implementations:
Don't cancel the push until after receiving the pushed response headers (since the response headers contain ETag and/or Last-Modified). If the pushed resource is already cached, the browser would convert the pushed response to a 304 and cancel the push. However, IMO, this waits too long to cancel the push.
Add conditional headers like If-Match to the PUSH_PROMISE so the browser knows exactly which resource is being pushed. This is a good idea but it would need to be spec'd out before we could implement it. https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0522.html ...
所以我期望的可能（通过读取 PUSH_PROMISE 中发送的一些 header-information 来帮助浏览器检查缓存资源的有效性）现在是不可能的，但最终会。
除此之外，似乎 cache-digest 将在未来某个地方在浏览器中实现，这将更加有效，因为可以避免在服务器上进行不必要的推送。 Chrome 已经在着手解决这个问题，如下所示：https://docs.google.com/document/d/1HhmyzKUPuWcCs8wG_GLSu3mvptygXtO2mBl5xlmEB-4/edit#
说的不对请指正