基本上，如果您设置标头 Vary：接受响应，因为您正在使用 Accept 请求标头进行内容协商，则使用 http2_push_preload 的 http2 推送不起作用。我正在使用内容协商向支持它的客户端发送(http2 推送(webp 图片而不是 jpg。
HTTP/2 Push适用于.js，.css文件以及同一调用中的所有文件，并在Chrome DevTools中显示"Push/Other"，但在这种特殊情况下失败(jpg内容协商到webp(，并且在Chrome DevTools中仅显示"其他"(未推送(。
brotli，gzip压缩的内容协商都可以正常工作，并且使用Vary：接受编码正确推送，对于使用Vary：接受语言的语言也是如此。
仅变化：接受失败。 请帮助我即将放弃。
PS：我正在通过nginx源代码 https://github.com/nginx/nginx/blob/master/src/http/v2/ngx_http_v2.c。做一个 Crtl+F，你会发现只有"接受编码"和"接受语言"的情况，没有"接受"的情况。所以我认为nginx还不支持"接受"的情况？？
P.P.S：我没有过度推送，只是使用http2推送作为英雄图像。
编辑：这是nginx网站上的错误票，供那些想要跟踪它的人使用： https://trac.nginx.org/nginx/ticket/1851 https://trac.nginx.org/nginx/ticket/1817
编辑2：Nginx团队回应说，出于安全原因，他们不会支持它(你可以在重复的错误帖子中找到回应(，我相信这是由于像CDN这样的不同来源的推动？无论如何，我需要这个功能，所以剩下的唯一选择是：
-
创建自定义修补程序或软件包。
-
使用其他一些支持它的服务器软件。
-
在网站代码中手动实现一项功能，以重写.jpg路径，以便在请求来自支持 webp 的客户端时.jpg.webp。
(我不放弃:P(
我对此并不完全感到惊讶，Apache也是如此。如果您希望对此进行更改，建议使用 nginx 提出一个错误，但如果他们没有优先考虑它，也不会感到惊讶。
浏览器似乎也不能很好地处理这种情况。
HTTP/2推送充满了过度推送的机会，这是一个例子。如果客户端不支持 WebP，则不应推送，并且您通常不会知道此时拥有的信息。例如，当您要求输入HTML时，Chrome似乎会在accept标题中发送webp，但Firefox没有。
预加载是一个更好、更安全的选项，它将尊重不同的标头和缓存状态。