問題タブ [vary]

同じ URL が同じリソースの異なるコンテンツ タイプを提供できる場合、 Vary に Accept を含める必要がありますか? それとも、ブラウザのキャッシュとプロキシはそれを暗黙的であると認識していますか?

例：

この対応

またはこれ

私は symfony 3 を使用しており、次の .htaccess ファイルがあります (このメッセージの一番下に'problem .htaccess'として添付されています)。Web サイト gtmetrix.com (pagespeed を使用) を使用してサイトを最適化していますが、.css および .js ファイルで次のエラーが発生します。

Header append Vary User-Agent明らかにaccept-encodingとは言っていないと言う前に..

1.) ( .htaccess で "Vary: Accept-Encoding" ヘッダーを指定する方法を既に見ました)、これを設定する方法について説明しています。

2.)リストしたコードは、同じサーバーの別のサイトで動作しますが、エンコーディングのエラー メッセージが表示されません。、つまり、私が持っているコードはとにかく機能するはずです (そして、他のサイトには main.css と main.js もあります)。その htaccess ファイルの唯一の違いは、それが symfony ではなく SLIM フレームワーク用であったため、次のようになったことです。

スリム フレームワーク (他サイト .HTACCESS)

Symfony 3 フレームワーク (.HTACCESS の問題)

質問:Header append Vary User-Agent symfony フレームワークまたはその .htaccess ファイルについて、コマンドの使用を許可しない違いは何ですか?

アップデート

そこで、いくつかの実験を行った後、symfony の .htaccess ファイルを Slims と同じように変更しました。必要な唯一の違いは、DirectoryIndex app.php の行を Slims .htaccess ファイルに追加し、代わりに app.php に書き換えるように指示することだけでした。 index.phpの、それでもエラーは解決しません。これは、おそらく htaccess ファイルではないことを示していますが、アセットを作成しようとしている方法でしょうか?

コードでは、TWIG テンプレートでは次のようになります。

アセットを使用しているため、エンジンでそのリソースのエンコーダーに何かをしているからでしょうか? それがどのように行われるかはわかりませんが、今のところ他にどこを探すべきかわかりません。

アップデート #2

このミステリーは大きく前進しました。Vary-encoding メッセージが消えるようになりましたが、その理由はよくわかりませんが、main.css ファイルのファイル サイズが重要であることはわかっています。

main.css に次の内容がある場合、vary:accept エンコーディング ヘッダーの指定に失敗しますか? そもそも小さすぎて圧縮できなかったからでしょうか？

ただし、代わりに次の main.css コンテンツを指定すると、gtmetrix でメッセージが消えます。

JavaScript にはまだエラーがありますが、JavaScript ファイルにランダム関数を追加し続けて、エラーが解消されるかどうかを確認します。現在、私のJSファイルは次のとおりです。

更新 #3:

実際、ファイルサイズが原因で、jsファイルを..

ヘッダーのさまざまなエンコード エラーを小刻みに動かして解消するのに十分でした。

アップデート #4

このページ ( https://www.fastly.com/blog/best-practices-for-using-the-vary-header ) を読んでいましたが、明らかに mod_deflate を使用している場合、正しい Vary ヘッダーが応答に自動的に追加されます。そのため、main.css ファイルと main.js ファイルが小さいときに、mod_deflate が提案された変更を上書きしていた可能性が非常に高いです。

新しい質問：

Header append Vary User-Agentコマンドを追加しようとするときにファイル サイズが問題になるのはなぜ ですか? この場合、gtmetrix (pagespeed) からの速度最適化の提案を無視する必要がありますか? または、mod_deflate が上書きされている場合、これも問題になりますか? もしそうなら、mod_deflate が引き起こすヘッダーの上書きを修正するにはどうすればよいですか?

静的ファイルをブラウザに短時間(10 秒)キャッシュするようにしようとしています。ページを更新すると正常に動作しているようです。- 新規の場合は 200 - 最初の 10 秒間にソフト リフレッシュした場合はキャッシュから 200 - 10 秒以上経過した場合は 304。

Http ヘッダー 'Vary': 'Accept-Encoding' を追加するたびに、機能が停止します。つまり、ブラウザーのキャッシュが機能しなくなります (常にサーバーにヒットします)。これは、Http ヘッダー 'Vary' を追加するたびに、 Http 要求が if-modified-since または if-none-match の送信を停止するために発生します。

キャッシュ制御と可変互換性は連携していますか?

誰かが解決策を提案できる場合に備えて、HTTP リクエストとレスポンスを残します。

Expressでは、静的ファイルの応答ヘッダーを設定するための次の構成があります。

Django 1.11 に基づくかなり複雑な webapp があります。少し前に、ユーザーが「他の誰かのビュー」を取得していると報告し始めました。memcached は@cache_page(xx)、キャッシュ猶予期間内のセッションを区別せずに、デコレーターによってキャッシュされた html をユーザーに提供しました。

さらに調査したところ、場合によってVary: Cookieはヘッダーが欠落しており、間違った「セッション」が提供されていることがわかりました。奇妙なことに、curl を使用してバックエンドにクエリを実行した場合にのみ表示されました (セッション、ユーザーなどがない -> バックエンドがキャッシュされたビューでログに記録されました)。

残念ながら、この問題は再現が非常に難しく、発生する場合と発生しない場合があります。単純な Django アプリをゼロから作成して、原因を確認できるかどうかを確認することさえあります。@cache_page観察されたのは、が削除またはlogin_required追加されたときに問題が発生しないことです。

ビューからすべての @cache_page デコレータを削除することになりましたが、本番環境では問題は観察されませんでしたが、これは回避策であり、原因を知りたいです。

誰かが原因のヒントを持っていれば、それは大歓迎です!