nginx Http2 Push 在 Vary 時失敗：接受 header 設置

Question

基本上，如果您設置 header 變化：接受您的響應，則使用 http2_push_preload 的 http2 推送不起作用，因為您正在使用接受請求 header 進行內容協商。 我正在使用內容協商向支持它的客戶端發送（http2 推送）webp 圖片而不是 jpg。

HTTP/2 推送適用於 .js、.css 文件，所有這些文件都在同一個調用中，並在 Chrome DevTools 中顯示“推送/其他”，但對於這種獨特的情況（jpg 內容與 webp 協商）失敗，並且只顯示“其他” （未推送）在 Chrome DevTools 中。

brotli 的內容協商，gzip 壓縮都可以正常工作，並使用 Vary: Accept-Encoding 正確推送，對於使用 Vary: Accept-Language 的語言也是如此。

只有變化：接受失敗。 請幫助我正在放棄。

PS：我正在通過 nginx 源https://github.com/nginx/nginx/blob/master/src/http/v2/ngx_http_v2.Z4A8A08F09D37B7379564903840384 做一個 Crtl+F，你會發現只有“Accept-Encoding”和“Accept-Language”的案例，“Accept”沒有。 所以我認為 nginx 還不支持“接受”案例？

PPS：我沒有過分推，只使用 http2 推送英雄圖像。

Edit: Here's bug ticket on nginx site for those who want to track it: https://trac.nginx.org/nginx/ticket/1851 https://trac.nginx.org/nginx/ticket/1817

編輯 2：Nginx 團隊回應說，由於安全原因，他們不會支持它（您可以在重復的錯誤帖子中找到響應），我認為這是由於來自 CDN 等不同來源的推送？ 無論如何，我需要這個功能，所以剩下的唯一選擇是：

1. 創建自定義補丁或 package。

2. 使用一些其他支持它的服務器軟件。

3. 如果請求來自支持 webp 的客戶端，則在網站代碼中手動實現將.jpg 路徑重寫為.jpg.webp 的功能。

（我不放棄：P）

Answer 1

我對此並不完全感到驚訝， Apache 也是如此。 如果你想改變這個建議用 nginx 提出一個錯誤，但如果他們沒有優先考慮它也不會感到驚訝。

似乎瀏覽器也不能很好地處理這種情況。

HTTP/2 推送充滿了過度推送的機會，這就是一個例子。 如果客戶端不支持 WebP，您不應該推送，而且您通常不會通過此時掌握的信息知道這一點。 例如，當您詢問 HTML 時，Chrome 似乎會在accept header 中發送 webp，但 Firefox 不會。

Preload 是一個更好、更安全的選項，它將尊重不同的標頭和緩存狀態。