Is origin cache control respected when cf.cacheEverything is set by a worker fetch?

Hi all, :grinning: I’m working along with workers and I’m seeing some output that’s confusing me.

I am noticing that the Age header coming back from CF on a cache hit (default cache space) is a larger value than the value I have set as a TTL on my origin server. I’m using origin cache control.

I am wondering about the interaction of:

  • cf.cacheEverthing set to true
  • Cache-Control headers from server with 3-second ttl
  • a page rule like this:
...
      "actions": [
        {
          "id": "browser_cache_ttl",
          "value": 0
        },
        {
          "id": "explicit_cache_control",
          "value": "on"
        }
      ],
      "priority": 12345,
      "status": "active",
...

Again, I am noticing that the Age header coming back from CF with 2153 seconds, which is much more than 3 seconds. I do not see revalidating happening on my server logs.

I read this this unanswered topic with similar key words that asks for documentation, but got no hints there.

It seems like this configuration ignores the TTL from the origin server Cache-Control header and uses the default value for Cloudflare. Does this seem possible?

Caching, admittedly, always confuses the heII out of me, so I might be missing something, but shouldn’t browser_cache_ttl and explicit_cache_control be mutually exclusive? After all you say Cloudflare should tunnel through the cache control header on one hand, on the other hand you explicity set that header.

Also, how did you manage to set browser_cache_ttl to zero, from what I can tell the minimum value should be “1800”.

That is a good question. Cloudflare does appear to cache more than just the resource itself (= also response headers), however I understand “Origin Cache Control” only applies to the actual Cache-control header and not Age. https://support.cloudflare.com/hc/en-us/articles/115003206852-Understanding-Origin-Cache-Control would have more on that.

Now even more I know, why caching always confuses me :smile:

Hi Sandro, I was also surprised to find out the API representation of ‘respect existing headers’ is a zero value.

Here’s that same rule in the dashboard:


and in the API response:

...
"actions": [
  {
    "id": "browser_cache_ttl",
    "value": 0
  },
  {
    "id": "explicit_cache_control",
    "value": "on"
  }
],
...

I’m still looking for a more concrete answer to the original problem.

Alright, that probably explains that value.

I still think these two settings are somewhat mutually exlusive, hence I am not sure why you apply them at the same time. Also, as I mentioned, I am not sure if explicit_cache_control controls the Age header at all.

Anyhow, I guess my caching background is exhausted at this point, maybe @MVP have more insight.

1 Like

Age header is purely representative of CF cache TTL (Edge cache TTL) and not Browser cache control header.

1 Like

:man_facepalming:t2: I should have just read the documentation :smile:
.https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Age

The Age header contains the time in seconds the object has been in a proxy cache.

Caching, almost as cumbersome as string parsing.

“There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.”

1 Like

Hi eva2000 and Sandro, I think I found the answer.

I changed my cache-control header to contain a s-maxage directive, and the explicit cache control does seem to respect this directive. I see Age is now no longer than the seven seconds I set.

So, the Origin Cache Control feature AKA explicit_cache_control in the API relates to the s-maxage directive in the cache-control http header.

Next I went to find in the docs where I could have known this from…

1 Like

yes s-maxage is to control CF cache so expected :slight_smile: