Have you considered adding "Cache-Control: Immutable" to these objects which will never require re-validation?  This will prevent the browser from attempting an If-Modified-Since request.

https://hacks.mozilla.org/2017/01/using-immutable-caching-to-speed-up-the-web/

David

On Thu, Nov 23, 2017 at 10:07 AM, Veiko Kukk <veiko.kukk@gmail.com> wrote:
In addition to my previous e-mail, headers that are provided by source to ATS:

< HTTP/1.1 200 OK
< Content-Length: 1185954
< Accept-Ranges: bytes
< Last-Modified: Mon, 02 Nov 2015 17:56:12 GMT
< Etag: 92ef40097ba87bdf09efcf7e1cefd32a
< X-Timestamp: 1446486971.39466
< Content-Type: application/octet-stream
< Content-Disposition: attachment; filename="ABIYohNyPrJNjvFsAdgN5wc8D-8Yo4ZO.m4s"; filename*=UTF-8''ABIYohNyPrJNjvFsAdgN5wc8D-8Yo4ZO.m4s
< Expires: Thu, 23 Nov 2017 15:27:30 GMT
< X-Trans-Id: tx3a0af5473d5c41d38195c-005a16e30d
< X-Openstack-Request-Id: tx3a0af5473d5c41d38195c-005a16e30d
< Date: Thu, 23 Nov 2017 15:02:37 GMT
< X-IPLB-Instance: 12631

I assume, Expires header is here to blame and must be overriden in ATS config, but how? I don't have control over source, its Openstack Swift object storage.

Veiko


2017-11-23 16:35 GMT+02:00 Veiko Kukk <veiko.kukk@gmail.com>:
Hi,

Could ATS in reverse proxy mode be configured such way that it would never try to revalidate from source? It is known that in our case, object never changes (and is never refetched from source) and it is desirable to avoid any source validation. Validation verification adds significant overhead and we need to avoid it. Response to client with TCP_REFRESH_HIT would take 100-200ms instead of 0-10 in case of direct local TCP_HIT.

I've configured following:
dest_domain=.*.source.tld action=ignore-no-cache
dest_domain=.*.source.tld revalidate=9999d
dest_domain=.*.source.tld ttl-in-cache=9999d

CONFIG proxy.config.http.cache.when_to_revalidate INT 3
CONFIG proxy.config.http.cache.required_headers INT 0

But i still get TCP_REFRESH_HIT even when 9999 days have not passed (obviously).

NB! ATS is used as internal cache and our 'client' never explicitly requests revalidation.

Thanks,
Veiko