web-dev-qa-db-ja.com

キャッシュ制御ヘッダーが繰り返されます。有効かどうか？ （Nginx）

Nginxに次のように構成されたリソースがあります。

location ~ foo\.js$ {
    add_header Cache-Control public;
    expires 1d;
}

これをFirebugで開き、ヘッダーを見ると、次のように表示されます。

Cache-Control   max-age=86400, public

このサイトはHTTPSを使用しているので、max-age> 0 AND publicでない限り、ブラウザは明らかにキャッシュしないので、正しく取得できることを確認したいと思います。 これを参照

しかし、curl -Ik https://...を使用するとNginxで何が起こるかというと、次のようになります。

...
Expires: Sat, 22 Jan 2011 18:23:36 GMT
Cache-Control: max-age=86400
Cache-Control: public
...

Cache-Controlヘッダーを繰り返します！明らかにFirebugは気にしません。しかし、それは正しいですか？

ExpiresとCache-Control（publicを含む）を1行で設定するより良い方法はありますか？

nginxcache-control
29
Peter Bengtsson

はい、複数のCache-Controlヘッダーを使用することは有効で同等です。

HTTP 1.1仕様 から：

同じフィールド名を持つ複数のメッセージヘッダーフィールドは、そのヘッダーフィールドのフィールド値全体がコンマ区切りのリストとして定義されている場合にのみ、メッセージに存在する可能性があります[つまり、＃（values）]。メッセージのセマンティクスを変更せずに、後続の各フィールド値を最初のフィールド値にコンマで区切って追加することにより、複数のヘッダーフィールドを1つの「フィールド名：フィールド値」ペアに結合できる必要があります。

定義方法 により、このプロビジョニングがCache-Controlヘッダーに適用されることを確認するのは簡単です。

Cache-Control = "Cache-Control" "：" 1＃cache-directive

上記の行を解釈する方法を理解するには、仕様の 表記規則 を参照してください。 1#は、「1つ以上のコンマ区切りのリスト」を意味します。

30
jaredjacobs

異なる構成で同じ問題が発生していました。私にとってうまくいったのは、ヘッダーを設定する2行の順序を変更し、「サーバー」の開き角かっこの直後にヘッダー設定を配置することです。これにより、おそらくすべてのオブジェクトにヘッダーが設定されますが、「if」ステートメントでも機能する可能性があります。


server {
   expires     31d;
   add_header  Cache-Control public;

   server_name example.com
   ...
}

Add_headerは、expiresディレクティブの前にヘッダーを送信して、変更する時間を確保しているようです。

6
Ross