Is there current documentation about how Cloudflare does (or doesn't) cache redirect responses (301/308/etc) from an origin? Info was apparently removed from the doc?

Since 301 and 308 redirects are intended to be permanent, it would be nice if Cloudflare could cache them, maybe not for eternity but for a while at least.

(Yes I know you can redirect on the Cloudflare side with Page Rules or Bulk Redirects so that the request never hits the origin, but in many cases I prefer to handle the redirects on my origin for various reasons)

Here’s the curious thing, if you look here: How long is a 302 redirect saved in browser? - Stack Overflow

It links to a page that apparently no longer exists but redirects to https://developers.cloudflare.com/cache/about/default-cache-behavior

The StackOverflow post implies that the following text used to exist:

If no cache headers are provided (no Cache-Control or Expires) and the url is cacheable (.jpg, .css, .js etc.) then CloudFlare caches both 301 and 302s. We cache 301 for a couple of hours and 302s for a shorter period of time (~20 minutes).

But if you search for that text, it doesn’t seem to exist anywhere.

However, some quick testing seems to indicate that the text is (still) accurate

It does seem that 301’s can be cached in some cases, but not 308’s. Why not?

Also choosing whether or not to cache redirects based on the file extension is really silly… it’s not a file, it’s a redirect, so why does the extension matter? Why not just cache it?

To try to highlight the weirdness of it, I confirmed the following:

test.html redirecting to test.jpg, the redirect is NOT cached
test.jpg redirecting to test.html, the redirect IS cached

It seems to only pay attention to the extension of the “redirect from” and not the extension of the “redirect to”

Any way to get more comprehensive caching of redirects?

I thought about doing something with “cache everything” page rules, but there’s apparently no way to make it only apply to redirects.

Cloudflare does cache the 301 rediredcts under certain cyrcumstances, but not the 308.

You can easily test that yourself by creating these types of redirects with a .htaccess or a nginx.conf like this:

.htaccess

Redirect 308 /testredirect308 https://target.com/path
Redirect 301 /testredirect301 https://target.com/path

Then call the links (https://yourdomain.tld/testredirect301 & https://yourdomain.tld/testredirect308) at least twice with disabled browser cache and check the cf-cache-status header.

You will see it will not be cached. But once you turn on “Cache Everything”, it will cache the 301, but not the 308 as I said above.

I don’t have a documentation handy, but I hope this little test answers all your questions :slight_smile:

Another way of having the redirect done directly on Cloudflare is, implementing them there with for example pagerules.

Yeah that basically matches what I had gathered from research and testing

I don’t want to cache HTML but I do want to cache redirects (even if they’re from/to HTML)… I guess I’m out of luck, doesn’t seem to be possible currently

and I just recently finished switching my origin over to use only 308s instead of 301s… now I’m thinking I might be better off switching back :frowning:

Don’t switch back because Cloudflare does not support something (yet), open a support ticket if you think this should be added and share the ticket #ID with us here.

Do you know the difference between these redirect codes and when to use them?
I doubt most people don’t and therefore miss-use them, but since I don’t know what exactly you are doing with it I can’t tell if you are using it right or wrong.

In general: use the 301 :slight_smile:

1 Like

Yes I’m aware of the history and that when you’re dealing purely with GETs, there’s no real difference between 301 and 308, and that certain ancient browsers don’t understand 308

What prompted me to switch my server over to 308’s was noticing that Cloudflare Pages seems to exclusively use 308s for all the automatic redirection it does, for example removing index.html from URLs. So it seems like Cloudflare is implying that 308’s are “ready for prime time” in terms of browser support. So why not use them?

I run low-traffic personal/hobby websites so if a couple IE10 users get locked out I don’t really mind, in fact, they’re already effectively locked out of all my stuff because of my TLS configurations so lack of 308 support is a moot point.

Not just this. The SEO signal also is different. With a 301 you inherit the SEO value to the target site and you signalize that the URL you are redirecting is now (moved) to the new target. The 308 is a more simple redirect and does not signalize, that the source is to be found at the target. So choose wisely when to use a 308 and 301.

Someting to read about the 301 & 308

Both IMHO should be treated the same, when it comes to caching, so I think this is something to fix at Cloudflare. Will see if I can set up a good test-example and convince the devs to adapt to also caching the 308 if “Cache Everything” is activated.

On top of this I think 301 & 308 even should be cached if no “Cache Everything” is active, since they are permanent redirects and without caching are not making the web faster.

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