Does Cloudflare support stale-while-revalidate?

6
votes

Cloudflare documents a list of directives for the Cache-Control header, including stale-while-revalidate.

  • stale-while-revalidate=<seconds>
    When present in an HTTP response, the stale-while-revalidate Cache-Control extension indicates that caches MAY serve the response in which it appears after it becomes stale, up to the indicated number of seconds since the object was originally retrieved.

I set my Cache-Control header to public, max-age=0, stale-while-revalidate=30 but I never seem to get a cache hit. Does Cloudflare actually support this?

2
cachingcloudflarehttp-caching
sorry for asking here, but just saw your question and its locked community.cloudflare.com/t/does-stale-while-revalidate-work/… do you know if they are suppring it now? I tried to test and it seems they still not support it but I am not sure - Amir Bar
@AmirBar I have just done some testing myself, and i cant get it to serve stale. I can get it to serve me a stale response IF i open another browser and hit same URL. But the initiator still doesn't get a stale response, thus it is blocked. This behaviour is the same as if you dont include the "stale-while-revalidate" setting in the Cache-Control header. - mslot
I've tried all day to get it working. Even without this header I managed to get STALE responses if I take my server down - unless I send must-revalidate. But I couldn't get stale-while-revalidate to do anything different. - Simon_Weaver

2 Answers

1
votes

If you put max-age=0, then effectively nothing is cached, if so, then there is nothing to serve. Try with max-age=1 - that should give some results in that 30 sec. period.

0
votes

Ran into this question / issue today, and the Cloudflare documentation is not very clear, but there is a clue under their examples section on this page.

Cache-Control: max-age=600, stale-while-revalidate=30

This configuration indicates the asset is fresh for 600 seconds, and can be served stale for up to an additional 30 seconds to parallel requests for the same resource while the initial synchronous revalidation is attempted.

So, Cloudflare does support the directive, however their implementation is a bit different than one might expect. Essentially the first request made to your server once the cached content is expire will result in a synchronous request to your Origin, which that client must wait for (the behavior most people don't want).

However, there is some support because any parallel requests (e.g. made by other clients) for that same resource will get the old / cached content instead (with a CF-Cache-Status: UPDATING). Tested this and was able to confirm behavior.

In this way, if you have a very slow origin response, or a very popular cached resource, only a single client / user is held up, and the rest get served up the stale cached copy from Cloudflare. Better than nothing.