Negative caching not honoring negative_caching_lifetime?

[Mark Moseley <mo...@gmail.com>]

(ATS 4.1.1, Ubuntu Precise 64-bit, reverse proxy)

I wanted to test microcaching and I noticed that I can't seem to get ATS to
revalidate under 3600 seconds. Tried with 4.0.2 too with similar results.

Anything I can think of for relevant configs (seems like pasting an entire
records.config would be too big, though I'll be happy to):

CONFIG proxy.config.http.cache.when_to_revalidate INT 0
CONFIG proxy.config.http.cache.heuristic_min_lifetime INT 1 # The only
setting I could find that was set to 3600, so I tried changing it

Here's an ATS reply for a page that I've got set up with an Expires of 10
seconds:

< HTTP/1.1 200 OK
< Date: Sun, 01 Dec 2013 15:45:34 GMT
< Content-Type: text/html
< Content-Length: 3
< Connection: keep-alive
< Server: Apache/2
< Last-Modified: Sun, 01 Dec 2013 06:59:50 GMT
< ETag: "3-4ec739c172273"
< Accept-Ranges: bytes
< Cache-Control: max-age=10
< Expires: Sun, 01 Dec 2013 15:44:21 GMT
< Age: 83
< Warning: 113 ApacheTrafficServer/4.0.2

A few minutes later it's up to Age: 282. I've got a packet capture to the
origin going and at no time did it attempt to revalidate.

I clearly have something misconfigured. I also noticed that error pages are
also being cached at 3600 seconds (let it run in a loop overnight and it
was 3600 seconds every time), despite:

CONFIG proxy.config.http.negative_caching_enabled INT 1
CONFIG proxy.config.http.negative_caching_lifetime INT 60


Anybody want to take a stab at what I'm messing up?

Re: Negative caching not honoring negative_caching_lifetime?

[Mark Moseley <mo...@gmail.com>]

On Sun, Dec 1, 2013 at 7:54 AM, Mark Moseley <mo...@gmail.com> wrote:

> (ATS 4.1.1, Ubuntu Precise 64-bit, reverse proxy)
>
> I wanted to test microcaching and I noticed that I can't seem to get ATS
> to revalidate under 3600 seconds. Tried with 4.0.2 too with similar results.
>
> Anything I can think of for relevant configs (seems like pasting an entire
> records.config would be too big, though I'll be happy to):
>
> CONFIG proxy.config.http.cache.when_to_revalidate INT 0
> CONFIG proxy.config.http.cache.heuristic_min_lifetime INT 1 # The only
> setting I could find that was set to 3600, so I tried changing it
>
> Here's an ATS reply for a page that I've got set up with an Expires of 10
> seconds:
>
> < HTTP/1.1 200 OK
> < Date: Sun, 01 Dec 2013 15:45:34 GMT
> < Content-Type: text/html
> < Content-Length: 3
> < Connection: keep-alive
> < Server: Apache/2
> < Last-Modified: Sun, 01 Dec 2013 06:59:50 GMT
> < ETag: "3-4ec739c172273"
> < Accept-Ranges: bytes
> < Cache-Control: max-age=10
> < Expires: Sun, 01 Dec 2013 15:44:21 GMT
> < Age: 83
> < Warning: 113 ApacheTrafficServer/4.0.2
>
> A few minutes later it's up to Age: 282. I've got a packet capture to the
> origin going and at no time did it attempt to revalidate.
>
> I clearly have something misconfigured. I also noticed that error pages
> are also being cached at 3600 seconds (let it run in a loop overnight and
> it was 3600 seconds every time), despite:
>
> CONFIG proxy.config.http.negative_caching_enabled INT 1
> CONFIG proxy.config.http.negative_caching_lifetime INT 60
>
>
> Anybody want to take a stab at what I'm messing up?
>


Sending to the list is always the magic cure to finding the answer
yourself, minutes after you hit Send.

This line in config.cache was tripping me up:

dest_domain=. method=get revalidate=1h


Commenting it out gets ATS back to revalidating according to the Expires
limit for <3600 Expires.

I took it from the docs to mean "revalidate every hour, regardless of the
Expires limit", i.e. let Expires be long but be safe and do a conditional
revalidate anyway. Apparently it also means 'don't revalidate *until* that
time too'. Is that correct?