[PATCH] Disable ETag handling in slice filter

Maxim Dounin mdounin at mdounin.ru
Tue Dec 27 15:02:25 UTC 2016


On Tue, Dec 27, 2016 at 03:27:20PM +0100, Timo Beckers wrote:

> Hi,
> We use Nginx to locally cache large binary content. Cache efficiency
> is of high importance, so the slice filter is excellent for this
> purpose! Here's a (very) short relevant configuration snippet for a
> particular location we use:
> slice 1m;
> proxy_cache data;
> proxy_pass http://$host$request_uri;
> proxy_cache_key $uri$slice_range;
> proxy_set_header Range $slice_range;
> Since we've adopted the slice filter, we've been seeing a lot of 'etag
> mismatch in slice response' errors because the upstream provider
> serves content from multiple CDNs that provide the exact same URI
> namespace. For example, consider the following resource:
> /tpr/hs/data/7c/bf/7cbf4dbce9233a57ff6c1cbf84db77d8
> Level3 serves this resource with ETag 74bc439-54261c855fd64.
> Akamai serves this resource with ETag
> 1273157742232ec1b8d3afc4c41a2a9c:1480362585.
> Since we value cache efficiency over anything else, adding the host to
> the cache key is not an option. The alternative is pinning proxy_pass
> to one specific CDN, but that approach has several other downsides.
> So, I decided to try my hand at (slightly) altering the filter to make
> it more configurable, I've posted the result below. Further
> improvements might include:


    proxy_hide_header ETag;

instead, it should help.

The other side effect of this is that there will be no ETag in 
responses returned.  This is clearly a good thing in the scenario 
described, as ETag in your case is broken as it changes from one 
request to another.  Removing it altogether will also help clients 
to use range requests and local caching.


Maxim Dounin

More information about the nginx-devel mailing list