nginxでgzipを有効にしている場合のEtag header
nginxでgzipを有効にしている場合、アプリケーションサーバの返すEtag headerが取り除かれることがあるので注意
nginx 1.7.3以前はnginxのgzip compressionが行われる時には一切Etagを返却しなかった
nginx 1.7.3以後、以下の挙動になった
アプリケーションサーバの返すEtag headerがstrong etagの場合はweakにdowngradeされる
ただしnginxは "439acd9b0a89e"をstrong etagとはみなすが439acd9b0a89eをstrong etagとはみなさないことに注意
"で始まらない場合は単純に削除される
weak Etagはそのまま保全される
prefixW/をつけてW/"439acd9b0a89e"のような形式にすると無事届く
ただしupstream (アプリケーションサーバや別のnginx) でcompressionがすでに行われている場合はnginx側ではgzip compressionを行わないのでEtagの変換や除去も行わない
rack middlewareのRack::Deflaterを利用している場合など
NGINX performs compression before sending responses to clients, but does not “double compress” responses that are already compressed (for example, by a proxied server).
nginxが数台存在する場合は個々の設定を確認すること
curlでaccept-encoding headerの値を変えてテストしてみると良い
code:shell
Changes with nginx 1.7.3 08 Jul 2014
*) Feature: weak entity tags are now preserved on response
modifications, and strong ones are changed to weak.
Nginx removes the etag header when gzip is enabled unless the application returns a weak etag header.
もともとEtagを消していた理由は、gzipによりcontentの変更を行うのだから別物として扱うべきだ、という理由
nginx mailing list
nginx本体にその実装がなされたcommit
実際にテストしてみたら上記の通りの挙動になった