救助のためのETag

HTTPプロトコル、またはその一部であるサーバーからの応答であるHTTPプロトコルに、Last-ModifiedやETagなどの素晴らしいヘッダーがあることは秘密ではありません（詳細については、プロトコル仕様を参照してください）。 サーバーからコンテンツを受信するプロセスを高速化するか、以前のリクエスト以降に変更されていないデータをクライアントがダウンロードするのを防ぐために、これらのユーザーは強く推奨されます。



だからここに。 私にとって、ページのコンテンツが変更されたかどうかをクライアントに伝えるための、本質的に同じ2つのメカニズムが存在するという事実は、少し憂慮すべきものです。 少し。 もっと正確に言えば、ETagの目的がわからなかったのです。Last-Modifiedと別のユーザーケースが常にあった場合、想像もできませんでした（正直、この質問は本当に気にしませんでした）。



しかし、昨日まで、Last-Modifiedが対処できない状況に陥ったのはそれだけでした。 そして、この状況は非常に一般的です-多言語コンテンツ。 私の場合、現在の言語の識別子はサーバー上のセッションに保存されており、異なる言語のURLは同じであるため、実際に問題が発生しました。 サイトの最適化の作業を開始した後、条件付きキャッシュを有効にすると、言語切り替えが機能しなくなったことがわかりました。



これは、通常のLast-Modifiedの代わりにETagが役に立ちました。 そして、私はそれを非常に分かりやすく構築し始めました-すなわち、現在の言語とコンテンツの修正日を連結したものです。 この場合、言語を変更すると、クライアントは同じURLに対して異なるETagを受信し、それに応じてページを再度リロードしました。



結論として、一見しただけでばかげているとか馬鹿げていると思われる場合は、すぐに店内の同僚をrid笑したり、批判したりしないでください。 おそらく、私たち自身はまだ何かに気付いていません。