浏览器是否检查PUSH_PROMISE帧内的条件头？

Posted 2021-04-16

我知道浏览器可以发送RST_STREAM-frames来取消serverpush。

在Last-Modified内发送Etag或PUSH_PROMISE标题是否有意义？或者是to-be-pushed资源的验证仅基于他们的URI（正如Simone Bordet在两年前回答了以下问题）？

Does the browser cancel server push when a resource is in cache?

我找不到这个问题的确切答案。

答案

当HTTP / 2服务器推送资源时，它会生成要发送到客户端的PUSH_PROMISE帧，同时它会创建一个合成请求，该请求将被处理，就像远程客户端发送它一样。

请记住，PUSH_PROMISE框架表示客户端将为该资源做出的请求，而不是响应。

通常，PUSH_PROMISE帧头的内容和合成请求的头部是相同的，但是 - 根据实现 - 可能不是这种情况。

标题Last-Modified或ETag只在响应中有意义，因此将它们添加到PUSH_PROMISE帧是没有意义的。

将If-Modified-Since等其他请求标头添加到PUSH_PROMISE是否有意义取决于是否将相同的标头用于合成请求。如果使用相同的标头（通常是这种情况），则添加标头（如If-Modified-Since）仅对服务器端处理有影响：服务器在处理合成请求时可能会生成304 Not Modified。

但是，服务器发送资源的PUSH_PROMISE，然后是304会很奇怪。如果服务器知道客户端已经缓存了资源，那么它也可以跳过发送PUSH_PROMISE。

将Last-Modified等响应头添加到PUSH_PROMISE框架没有意义，因为PUSH_PROMISE表示请求。

添加条件请求标头（例如If-Modified-Since）通常要求服务器了解先前为客户端提供了哪些资源：它必须知道资源是否已经被提供，以便将304发送到客户端以获取推送的资源客户端使用其缓存中已存在的资源。

另一答案

经过深入搜索后，我想我找到了答案：

pushBuilder's Api对.lastModified()说：

设置用于条件推送的最后修改日期。

和.etag()：

设置要用于条件推送的etag。

我误解了这些解释和想法，指定的值被发送到PUSH_PROMISE内的浏览器，以帮助它决定是接受推送文件还是取消流（通过发送RST_STREAM）。

事实上，这些值似乎告诉服务器，如果它必须推动......或不。通过将文件的last-modified-date设置为.lastModified()，我得到了Simone Bordet在上面的评论中描述的行为：即使文件在我的缓存中不存在，也发送了304。

所以现在很清楚，在不知道客户端缓存中究竟是什么的情况下设置这些值是没有意义的。

像PUSH_PROMISE中的条件标题似乎现在不存在：我没有在HTTP2规范中找到任何关于它的内容，在阅读chrome的问题跟踪器时，我发现Tom Bergan在开放时评论了这个（02.01.2017）问题（https://bugs.chromium.org/p/chromium/issues/detail?id=232040#c62）：

...我认为处理这种情况的更好方法是在推送的响应与缓存的资源匹配时将推送的响应转换为304。有两种可能的实现：

1. 在收到推送的响应头之前不要取消推送（因为响应头包含ETag和/或Last-Modified）。如果推送的资源已被缓存，则浏览器会将推送的响应转换为304并取消推送。然而，IMO，这等待太长时间才能取消推动。
2. 将像If-Match这样的条件标头添加到PUSH_PROMISE，以便浏览器确切地知道正在推送哪个资源。这是一个好主意，但在我们实现它之前需要进行规范。 https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0522.html ......

所以我期望的可能性（帮助浏览器通过读取PUSH_PROMISE中发送的一些头信息来检查缓存资源的有效性）现在是不可能的，但最终会是这样。除此之外，似乎cache-digest将在未来的某个地方的浏览器中实现，甚至更有效，因为在服务器上可以避免不必要的推送。 Chrome已经在研究这个问题了，可以在这里看到：https://docs.google.com/document/d/1HhmyzKUPuWcCs8wG_GLSu3mvptygXtO2mBl5xlmEB-4/edit#

如果我说错了，请纠正我。