<div dir="ltr"><div>I am serving dynamic requests behind the Nginx HTTP server. HTTP requests are mostly from mobile HTTP clients. That's is why I care about two things.</div><div><br></div><div>1. Do not send the same representation twice: Use ETag caching mechanism.</div>
<div>2. Make better us of available bandwidth: Use Accept-Encoding HTTP compression.</div><div><br></div><div>Today I noticed that these two don't match. My application sets the ETag header in the response, but when I set the 'Accept-Encoding: gzip' in the request header, nginx clears the ETag header when gzipping on-the-fly.</div>
<div><br></div><div>I understand why this is: If two responses have the same ETag, their bodies should be byte-for-byte comparable. When the content is gzipped, and actually modified, this is of course not the case. The gzipped response is not equal to the non-gzipped response. </div>
<div><br></div><div>That's why there are two ETag validation mechanisms. A strong validation, used in case of byte-for-byte comparable responses, and a weak validation, to indicate semantic equivalency. </div><div><br>
</div><div>In the case of weak validation an ETag would look like:</div><div>ETag: W/"123456789"</div><div><br></div><div>Why is Nginx stripping weak ETag validators in its gzip filter?</div></div>