Hello!

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:

Try

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
http://nginx.org/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel