Not caching - CF-Cache-Status Header Missing in response Despite Correct Setup

C

Cyb3r-Jak3•10/4/23, 12:20 AM

Workers run before cache rules take effect they will always run

C

Cyb3r-Jak3•10/4/23, 11:51 AM

I’d recommend open an issue on the docs asking for clarification on it but my understanding has been cache rules run and apply the headers needed but they don’t serve cache content as that comes before the origin.

Original message was deleted

C

Cyb3r-Jak3•10/4/23, 1:12 PM

Via the repo https://github.com/cloudflare/cloudflare-docs

GitHub

GitHub - cloudflare/cloudflare-docs: Cloudflare’s documentation

Cloudflare’s documentation. Contribute to cloudflare/cloudflare-docs development by creating an account on GitHub.

Original message was deleted

C

Chaika•10/4/23, 2:06 PM

I would think of it this way:

The rules run in a certain order and set specific "Flags" which are used at different points. Page Rules and Configuration Rules can both modify security things, it doesn't mean security runs then and there.
If you use a page rule or a cache rule to tell it to cache something, it sets the internal flags that way. However, caching comes at the very end, as part of the origin connecting part

C

Chaika•10/4/23, 2:10 PM

eeeh I just wouldn't treat the traffic sequence that way, Origin Rules as well are the 4th thing to run, that's not where the origin is connected to of course

C

Chaika•10/4/23, 2:10 PM

not sure how you could make a diagram that shows every single part and possible return, it would be interesting though

C

Chaika•10/4/23, 2:11 PM

one big thing where it lacks right now is the rules/steps that gets done when a request is being returned

C

Chaika•10/4/23, 2:11 PM

There's an explanation here why workers run before cache btw, by the tech lead of workers: https://community.cloudflare.com/t/cache-in-front-of-worker/171258/8

C

Chaika•10/4/23, 2:14 PM

Not sure if this was meant to state that if you have a worker that's using the cache API then whenever your worker is hit (cache invalidation etc) then you'll pay for invocations?

If this is still confusing: Yes, Workers always run before cache. If you want to use cache with your worker, you have to use the cache api, and yes that is always a invocation

C

Chaika•10/4/23, 2:16 PM

Soon for simple things, like redirects, that fit in 5ms of CPU and 2MB of memory, there will be snippets which don't cost you anything for each run: https://blog.cloudflare.com/cloudflare-snippets-alpha/
soontm

Original message was deleted

C

Chaika•10/4/23, 2:21 PM

We can just talk about that here instead.
You're using a worker, and cache api, and still never getting any hits?

C

Chaika•10/4/23, 2:25 PM

Workers will never be cached, without you using Cache API (match/put) inside of it, which will be an invocation

C

Chaika•10/4/23, 2:26 PM

It doesn't matter what headers or rules you use on it, Workers are simply invocated before/separate from any cache logic in CF. The most you can do is use Cache API inside of it

C

Chaika•10/4/23, 2:27 PM

Do you mean ..responses generated by workers?

You can view it that way, sure.
Another way to view it is that the Cache layer is inside of the Origin connecting part at the end, which is after Workers, and Workers return a response preventing an origin connection from happening

C

Chaika•10/4/23, 2:31 PM

You would just want to use the Cache API:
https://developers.cloudflare.com/workers/runtime-apis/cache/
https://developers.cloudflare.com/workers/examples/cache-api/
This allows your worker to interact with the Cloudflare cache, and match cached items to return / put new items in

so do I need to have at least 2 workers, one to generate origin content, and another to do a fetch and include cf: { ttl and "cache everything } " etc?

I don't think that would work, as you'd still be fetching a worker which doesn't have cache from a worker, regardless cache api is a lot simpler

C

Chaika•10/4/23, 2:33 PM

Worth noting as well:
Because the Cache API is going to require an worker invocation anyway, in your case if you were generating the content in the worker, it wouldn't really make any sense to cache items because it is likely slower then the worker just running again (and as per the tech leads post, workers are less expensive to Cloudflare/faster then cache). I understand your case is just an example, but in general it's worth keeping in mind

Original message was deleted

C

Chaika•10/4/23, 2:39 PM

Of course, no worries!

If it helps, I have an example of a worker generating a response and caching it I made a while ago:

export default {
  async fetch(request, env, ctx) {
    
    const url = new URL(request.url);
    const cache = caches.default;
    let response = await cache.match(request);

    if (!response)
{
    const html = `<!DOCTYPE html>
    <head>
      <meta charset="UTF-8">
      <meta name="viewport" content="width=device-width, initial-scale=1.0">
    </head>
        <body>
          <h1>  ${url} ------> ${new Date().toLocaleString()}"</h1>
          <p>This markup was generated by a Cloudflare Worker.</p>
        </body>`;
 
    response = new Response(html, {
      headers: {
        "content-type": "text/html;charset=UTF-8",
        "Cache-Control": "public, max-age=300, s-maxage=600"
      },
    });
      // ctx.waitUntil lets us return a response (without making the user wait for cache) but not end the worker invocation without first caching the response
      ctx.waitUntil(cache.put(request, response.clone()));
}
   return response;
  }

};

export default {
  async fetch(request, env, ctx) {
    
    const url = new URL(request.url);
    const cache = caches.default;
    let response = await cache.match(request);

    if (!response)
{
    const html = `<!DOCTYPE html>
    <head>
      <meta charset="UTF-8">
      <meta name="viewport" content="width=device-width, initial-scale=1.0">
    </head>
        <body>
          <h1>  ${url} ------> ${new Date().toLocaleString()}"</h1>
          <p>This markup was generated by a Cloudflare Worker.</p>
        </body>`;
 
    response = new Response(html, {
      headers: {
        "content-type": "text/html;charset=UTF-8",
        "Cache-Control": "public, max-age=300, s-maxage=600"
      },
    });
      // ctx.waitUntil lets us return a response (without making the user wait for cache) but not end the worker invocation without first caching the response
      ctx.waitUntil(cache.put(request, response.clone()));
}
   return response;
  }

};

export default {
  async fetch(request, env, ctx) {
    
    const url = new URL(request.url);
    const cache = caches.default;
    let response = await cache.match(request);

    if (!response)
{
    const html = `<!DOCTYPE html>
    <head>
      <meta charset="UTF-8">
      <meta name="viewport" content="width=device-width, initial-scale=1.0">
    </head>
        <body>
          <h1>  ${url} ------> ${new Date().toLocaleString()}"</h1>
          <p>This markup was generated by a Cloudflare Worker.</p>
        </body>`;
 
    response = new Response(html, {
      headers: {
        "content-type": "text/html;charset=UTF-8",
        "Cache-Control": "public, max-age=300, s-maxage=600"
      },
    });
      // ctx.waitUntil lets us return a response (without making the user wait for cache) but not end the worker invocation without first caching the response
      ctx.waitUntil(cache.put(request, response.clone()));
}
   return response;
  }

};

export default {
  async fetch(request, env, ctx) {
    
    const url = new URL(request.url);
    const cache = caches.default;
    let response = await cache.match(request);

    if (!response)
{
    const html = `<!DOCTYPE html>
    <head>
      <meta charset="UTF-8">
      <meta name="viewport" content="width=device-width, initial-scale=1.0">
    </head>
        <body>
          <h1>  ${url} ------> ${new Date().toLocaleString()}"</h1>
          <p>This markup was generated by a Cloudflare Worker.</p>
        </body>`;
 
    response = new Response(html, {
      headers: {
        "content-type": "text/html;charset=UTF-8",
        "Cache-Control": "public, max-age=300, s-maxage=600"
      },
    });
      // ctx.waitUntil lets us return a response (without making the user wait for cache) but not end the worker invocation without first caching the response
      ctx.waitUntil(cache.put(request, response.clone()));
}
   return response;
  }

};

https://cache-api-test.workers.chaika.me/

Original message was deleted

C

Chaika•10/4/23, 2:54 PM

Yea the Cache API still does care about that all: https://developers.cloudflare.com/workers/runtime-apis/cache/, you just need to also use it directly with Workers.
It also has a few other limitations like only working on Custom Domains, not workers.dev, because it uses your actual website's/zone's normal cache.

that 1 extra cache.put line to include

Make sure not to miss the cache.match, gotta check if it matches anything first, if it does serve that cached response, otherwise generate and .put

C

Chaika•10/4/23, 2:57 PM

because of the cache.match, it'll only show it on cached responses. You're hitting a multi-colo pop (LHR has mutiple colos/dcs, each with their own cache) as well, give it a few requests

C

Chaika•10/4/23, 3:02 PM

Yea and Workers run everywhere, on every CF machine, your worker is already there, and if it's running on the entire hostname no cold starts. Whereas cache is cloudflare colo/datacenter wide, requiring reaching out to another machine/other complications

Not caching - CF-Cache-Status Header Missing in response Despite Correct Setup

Similar Threads

Similar Threads

Similar Threads