资源在缓存中时，浏览器是否取消服务器推送? [英] Does the browser cancel server push when a resource is in cache?

问题描述

HTTP/2规范指示，如果客户端取消，则在PUSH_PROMISE帧中标识的任何资源都不会被推送.

The HTTP/2 specification indicates that any resource identified in a PUSH_PROMISE frame won't be pushed if the client cancels it.

当浏览器检测到缓存中已有资源时，应取消对该资源的推送.但是，我看不到浏览器如何检测到它.框架是否提供其他信息，例如etag或最后修改的信息，以使浏览器能够检测是否必须清除任何缓存项，或者是否可以取消推送?

When a browser detects a resource already in the cache, it should cancel the push for this resource. However, I don't see how the browser can detect it. Do the frames provide additional informations like etag or last modified to allow the browser to detect if any cache entry must be evicted or if the push could be canceled?

如果可能，可以节省一些带宽.但是，服务器推送似乎损害了所有客户端缓存的优化.

If it's possible, some bandwidth could be saved. However, it seems server-push compromises any client cache optimization.

推荐答案

在HTTP/2中，服务器将具有PUSH_PROMISE框架的资源的请求推送到客户端.

In HTTP/2 the server pushes to the client a request for the resource with a PUSH_PROMISE frame.

从服务器到客户端时，这不是响应，而是请求，客户端为获取该资源而发出的请求.

While going from server to client, this is not a response, but a request, the request the client would make to fetch that resource.

当客户端收到PUSH_PROMISE时，它可以查看URI，并找出该资源的缓存状态.浏览器通常对正常接收的资源和推送的资源使用不同的缓存. 如果缓存仍然有效，则客户端可以通过向服务器发送该流的RST_STREAM帧来取消推送的流.

When the client receives the PUSH_PROMISE, it can look at the URI, and figure out the cache status of this resource. Browsers typically use different caches for normally received resources and pushed resources. If the cache is still valid, the client may cancel the pushed stream by sending a RST_STREAM frame to the server for that stream.

同时，服务器启动推送资源所需的时间.这将生成HEADERS响应帧，其中将包含典型的响应头，例如etag. 当客户端收到HEADERS响应帧时，它还有一个取消流的机会，尽管-当然-DATA帧可能正在运行，可能全部在运行.

Meanwhile, the server starts what it takes to push the resource. This will generate a HEADERS response frame that will contain the typical response headers such as etag. When the client receives the HEADERS response frame, it has one more chance to cancel the stream, although - of course - DATA frames may be inflight, possibly all of them.

节省带宽可能很有趣，但是浪费一点带宽通常不是问题.从用户体验的角度来看，更重要的是等待时间，而推送机制则将等待时间减少了很多.

Saving bandwidth may be interesting, but it's typically not a problem to waste a little bandwidth; what matters more from the user experience point of view is the latency, and the push mechanism reduces that by a considerable amount.

我认为推送机制不会损害任何客户端缓存的优化；如果是这种情况，浏览器供应商将反对该功能，而大多数(如果不是全部)则实施此功能，可以在用户体验和减少延迟方面取得很好的效果.

I don't think the push mechanism compromises any client cache optimization; had this been the case, browser vendors would have fought against this feature, while instead most of them (if not all) implement it with very good results in user experience and diminished latency.

当然可以改善该机制，例如，使客户端和服务器在某些标头上达成共识，这些标头将提供有关所推送资源的更多信息，但到目前为止效果还不错.

Sure the mechanism could be improved, for example by having clients and servers agree on some header that will give more information about the resource being pushed, but so far works fairly well.

[免责声明:我是码头提交人] <<大约3年前，它是第一个为Java生态系统实现SPDY和HTTP/2推送的人(大约3年前)，一个href ="https://www.eclipse.org/jetty"> Jetty项目当然对更多感兴趣HTTP/2推送中的讨论和想法.

[Disclaimer: I'm a Jetty committer] Having been the first to implement SPDY and HTTP/2 Push for the Java ecosystem (almost 3 years ago), the Jetty Project is certainly interested in more discussions and ideas around HTTP/2 Push.

这篇关于资源在缓存中时，浏览器是否取消服务器推送?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！