URL の更新に対する ETag の利点

Question

ETag を使用すると、ブラウザは条件付き GET を実行できます。問題のリソースが変更されている場合にのみ、リソースを再ダウンロードする必要があります。ただし、ブラウザはサーバーがリクエストに応答するまで待つ必要があります。

ETag の代わりに、リソースを指す URL にトークンを導入することもできます。

http://example.com/css/styles.css?token=134124134

または

http://example.com/css/134124134/styles.css

どちらのアプローチでも、変更されていないリソースを再ダウンロードする必要がなくなります。

ただし、トークンを含む URL を使用すると、サーバーはリソースに遠い将来の有効期限ヘッダーを設定できます。これにより、条件付き GET にかかるラウンドトリップが節約されます。リソースが変更されない場合、それを指す URL も変更されません。

トークンを含む URL よりも ETag を使用することに利点はありますか?

Answer 1

私が考える読み取り専用リソースの主な欠点は、すべての静的リソースに対してこのアプローチを全員が採用すると、クライアント キャッシュがあらゆる種類の古いリソースでいっぱいになってしまうことです。

また、無駄なファイルを大量に保持し始めるすべての中間キャッシュについても考えてください。

このアプローチでは Web と戦っていますが、これが普及した場合は、何かを変更する必要があります。これはスケーラブルなソリューションではないためです。

限られたトークンのセットを使用し、トークンが再利用される前に古いキャッシュされたリソースが期限切れになるように有効期限を十分に小さく設定する、ある種のハイブリッド アプローチはできないでしょうか?

Etag は読み取り/書き込みリソースにも使用されますが、この場合、トークン ソリューションが機能しないのではないかと思われます。

Answer 2

最大の違い/潜在的な利点は構成だと思います。URL 設定はアプリケーション内で構成/セットアップする必要があります (たとえば、HTML には実際に値が含まれている必要があります)。ETag は Web サーバー全体に対して設定されるため、ETag を利用するために HTML を変更する必要はありません。

また、ETag は (正しく構成されていると仮定して) ファイルが変更されると変更されます。URL にトークンを追加するには、それに変更を指示する追加の「何か」が必要になります (HTML を編集する人や構成設定など)。

Answer 3

一定の URI をお持ちですか?