When will Cloudflare fully support stale-while-revalidate with asynchronous background revalidation?

Website, Application, Performance
1

Sadly Cloudflare still doesn’t properly support stale-while-revalidate (SWR).

The correct way for it to be implemented is for the client to always be served a cached object if it’s within the time set for SWR, and Cloudflare should fetch a fresh copy of the object from the server asynchronously if the object is stale.The only time a client should be served an object from the server is if the object in Cloudflare’s cache is older than the time set for SWR.

Cloudflare’s current implementation is: If an object is stale, it will not serve the stale object to the client while it asynchronously fetches an update to the cache. Instead it simply forces the client to wait for a fresh copy of the object from the server. If there is a second request made at the same time for the same object, that’s when it will serve the stale copy (so I’ve heard, I actually haven’t seen this happen yet).

The spec can be found here RFC 5861 - HTTP Cache-Control Extensions for Stale Content Fastly implemented this in 2014: https://www.fastly.com/blog/stale-while-revalidate-stale-if-error-available-today

There are a number of threads on the community going back over quite a few years asking for this. Some don’t even have any response from Cloudflare.

I’d like to hear the latest from Cloudflare:

  1. Will you be implementing stale-while-revalidate fully?
  2. If yes, is there a timeline?
  3. If no, why is that the case? What are the blockers?

Cloudflare states its mission as so:

Cloudflare is on a mission to help build a better Internet.

If we look at the SWR spec, we find this definition.

The stale-while-revalidate HTTP Cache-Control extension allows a cache to immediately return a stale response while it revalidates it in the background, thereby hiding latency (both in the network and on the server) from clients.

The part in bold I believe highlights why fully implementing this standard should be a priority for Cloudflare as it fits perfectly with the mission of the company. One of the main goals of any CDN is to reduce latency for clients, I’m struggling to understand why this feature hasn’t been adopted yet.

6 Likes
2

Cloudflare believes that they already do support SWR, but they’re just wrong, and they have no plans to learn more about this. (I expect no reply from Cloudflare on this thread.)

The “blocker” is purely a confusion on Cloudflare’s part. They think they already support SWR, and that the behavior you and I expect is not required by the SWR specification. @cs-cf explains Cloudflare’s position here:

Which is to say, under the SWR spec, the cache MAY serve stale responses up to the indicated number of seconds, but they don’t, so, they’re “compliant” with the SWR spec by simply not doing SWR.

I explained what was wrong with Cloudflare’s statement three years ago. There was no reply. Most of the threads you linked above have no reply, either, or no reply to the clarification showing that, indeed, they really are wrong here. Cloudflare wrongly believes that there’s nothing further to discuss.

As you can see, a handful of nerds nagging them in half a dozen threads over three years hasn’t helped, and it isn’t going to help this time, either.

The only way this gets better is if large, high-value Cloudflare customers raise this issue with Cloudflare, and perhaps not even then, because they literally do not understand that they’ve failed to implement SWR.

Worst of all, if you do need SWR, it is technically possible on Cloudflare by re-implementing it yourself in a “Cloudflare worker” service worker, at extra cost to you. Implementing SWR correctly would cost Cloudflare money!

As Upton Sinclair wrote, “It is difficult to get a man to understand something when his salary depends on his not understanding it.” Thanks to Cloudflare Workers, Cloudflare is now that guy.

P.S. Fastly’s SWR support works great!

5 Likes
3

P.S. Fastly’s SWR support works great!

Coincidence or not, Mark Nottingham, the author of RFC5861, works at Fastly. I think this says A LOT about Cloudflare.

I’ll start checking Fastly now as SWR is one of the most important features for me.

1 Like
4

Thank you both for replying, it’s good to know there are others who still desire this feature from Cloudflare.

SWR is pretty important, I was really hoping Cloudflare might come around but based on what you said it doesn’t seem likely. I think maybe I’ll have to go take a look at Fastly.

1 Like
5

Would love a reply from Cloudflare with information on whether there are any plans to update how SWR works?

1 Like
6

My understanding from the quoted text is that the first request won’t SWR, but all the other ones will. I don’t think it’s just that they don’t implement it at all.

7

That’s an understandable misreading, but they just don’t implement it at all, as I explained (and proved with test cases) three years ago.

They do have a feature that looks kinda like SWR if you squint and turn your head a little, a feature where parallel requests can receive stale UPDATING content during a slow revalidation. But that feature (which is genuinely interesting) is on by default, and isn’t affected by the SWR header. (Even setting stale-while-revalidate=0 doesn’t turn the feature off!)

3 Likes
8

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.

9

Thanks for your question and sorry it took so long to respond.

To begin, we agree that this feature is good for the Internet and something that we will look to implement soon. The reason this isn’t currently supported is a technical limitation stemming from long-standing technical debt. The good news is that we’re currently in the process of getting rid of these limitations so that we can safely support more async features like this one. In the meantime, I thank you for your patience and look forward to supporting this soon.

Alex

11 Likes
11

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.