I don’t see this official documentation you speak of. My specific question is not about what you can cache. But for how long, or rather how short of a time. The documents say free accounts can only set their edge and browser cache time to a minimum of 2 hours. But if you look at my OP you will see the cloudflare gui let me manually type in “30 Seconds” even though it’s a drop-down box and the drop-down only shows 2 Hours+
It’s not supposed to let me manually enter anything below 2 Hours cach TTL on a free account, yet it allows me and it functions at 30 second TTL.
PLEASE show me where the documentation says I can set for less than 2 Hours cach TTL for anything other than paid accounts.
I’m sorry if I conflated Bypass Cache on Cookie (another topic that is often asked about in this forum) with your Edge Cache TTL question. But the issue is essentially the same, a new feature is not clearly documented in terms of limits and the old documentation is neither removed nor updated.
The question you should be asking is not where it says you can, but where (apart from old documentation referring to Page Rules) it says you cannot.
From the same documentation I quoted from
If you select Eligible for cache, you can customize the following options:
Select Respect origin if matching requests will respect cache headers received from the origin server, or Override origin. If you wish to override the Edge TTL value, you need to select how long you want to cache resources in the Cloudflare global network.
In Status code TTL you can define the cache time-to-live (TTL) duration for one or more response status codes received from the origin server. This setting can be applied to a Single code status code, to a Greater than or Less than status code or to a Range of status codes. For more information, refer to Status code TTL.
It says nowhere you cannot set the amount of time you want, not to mention that the UI will let you do so. The availability section, where this kind of limit would be present, only talks about number of rules allowed per plan. And as I quoted in my previous post, when there was a limit of features only available to Enterprise Plan, in the Cache Keys section, it was explicitly stated.
Cache Rules is a tectonic plate shift as far as how Cloudflare caches stuff, and old rules don’t apply.
As a matter of fact, over a year before Cache Rules (and the whole Rules suite of products) was launched, Cloudflare started letting users set Edge Cache TTL to whatever time in seconds they wished, with CDN-Cache-Control and its sibling Cloudflare-CDN-Cache-Control. CDN-Cache-Control: Precision Control for your CDN(s) Again, the blog post doesn’t say anywhere what you can set in terms of time, but it doesn’t say what you can’t either.
So I understand your anguish in terms of wishing to see an explicit an unequivocal statement concerning the new status of Edge Cache TTL limits. But the way I see it (it’s only my opinion, I don’t speak for any company), the cat is out of the bag.
It would be very disappointing if Cloudflare, almost a year after a product is launched that lets you set your Cache Rules with whatever Edge Cache TTL you wish, decided it was time to pull the plug and just let websites break in the way. At a very minimum, I’d expect Cloudflare to either grandfather users for the rules they have in place, or set a generous amount of time for them to change their settings before any such move is adopted (which I doubt it will ever be.)
@cloudflare I really hope this isn’t a bug… But I’m pretty sure it is…
Let me start with saying, I hope you allow this for free accounts or at least give it to me for free for finding the bug…
My site is almost 100% JSON API data, with users requesting the same data over and over again, the data actually changes every 60 seconds, so a 30 second cache allows me to go from 1% cached data to 40% ish cached data… I do not make money off my site, which is why I have a free account. That said… I need 30 second edge expire, saves you bandwidth from having to hit my origin. so it benefits you as well to let me keep 30sec! see my graphs below, you can see when i enabled 30 sec edge cache.
My application will totally break if it caches for more than 60 seconds for all of the people that are going to say just use 2 hour cache, I can not.
Anyway, on to the bug I found, Cache Rules allows you to manually enter any value you want in the edge and browser TTL fields… If this is not a bug, then good job Cloudflare! I need this for my personal api projects. But… I’m going to assume its a bug. Please confirm, if it is a bug i need to disable the rule before you fix it and i serve my api peeps 2 hour old data.
@sdayman@cs-cf maybe you can help get this on someone’s radar for an answer? TL;DR: 30 second caching is allowed on free accounts if you manually enter a text value in the dropdown box location. Bug or feature? So I know if I can enable this rule without the potential bug getting fixed and breaking my json data.
@cloonan this post was retagged “DocFeedback” does that mean this is a confirmed feature and you retagged so they update the documents? I need to confirm if this is on purpose so I can safely enable. Otherwise its still a beta bug. I don’t get why someone from cloudflare can’t just give me a Yes or No
This page says Free minimum is 2 hours. Features by plan type · Cloudflare Cache (CDN) docs Yet I’m able to do 30 seconds. Is this 30 second cache allowed and not a bug? I need to know so I can enable my cache rule for my API JSON data. If it changes later (bug fixed) to 2 hours while I have the rule enabled it will break my whole site and serve 2 hour old data. This is why im looking for a YES its planned, or NO this is a bug.
I’d say that if something’s not documented (or explicitly documented otherwise), then you shouldn’t count on it. Like that time a while back when everybody could proxy wildcard DNS records (an Enterprise feature at the time). Then that “bug” was fixed, and later became an official feature.
If the docs change, then it’s a “yes.” For now, it’s a “no.”
Thank you, ill take that as a no. close as im going to get to actual devs answering i guess.
a shame its not a free feature anyway. I get that this is a business, but i would think allowing us to cache api calls at 30 seconds would save CF more money in bandwidth than a charged feature… assuming they pay based on bandwidth. I was only caching 30mb now im caching 8GB+ just in api calls, CF servers not having to transport that data from my origin. I better turn off the rules for now i guess.
To better understand the difference between a Page Rule with Cache Everything and Bypass Cache on Cookie settings, and a Cache Rule with an expression that excludes certain cookies, let’s step back and consider regular Cloudflare caching.
With default caching, no HTML page is cached by Cloudflare, with or without cookies. When you set a Page Rule with a Cache Everything setting, you’re telling Cloudflare to create an exception: cache my HTML for the URLs matching this Page Rule.
Page Rules are URL-based, and if you set Cache Everything to
you are instructing Cloudflare to cache your whole website, but could avoid caching certain HTML pages with another Page Rule matching a different subset of URLs, such as
with a Bypass Cache setting.
Bypass Cache on Cookie is a setting that is only available to Business and Enterprise plans. It adds another element to the Cloudflare Page-Rule-based caching logic, by allowing users to define certain cookies as trigger of a special, non-URL-based, bypass condition.
This is all part of the past. Now enters Cache Rules (beta).
Cache Rules was launched as part of the suite of Rules products, all based on the Ruleset Engine, which allows for a much more granular matching than URL only.
The documentation clearly states that Cookie (http.cookie) is one of the fields you can use as part of your matching expression (“When incoming requests match…”).
Here we are not “bypassing cache on cookie”, because we’re not instructing Cloudflare to cache everything on our website. Instead we’re instructing Cloudflare to only cache if the request matches an expression that can be as simple as
URI Path starts with / (equivalent to *example.com/* in a Page Rule),
or as complex as the use of 10 separate fields, one of which is Cookie, while some represent request header values (something that is just not possible with Page Rules.)
The same documentation clearly states that Enterprise plan is required for certain features, such as in the Cache Keys section:
Enterprise customers have these additional options for custom cache keys:
In the Query string section, you can select All query string parameters, All query string parameters except and enter an exception, Only these parameters and enter the parameters, or Ignore query string.
In the Headers section, you can include headers names and their values, check the presence of another header, and Include origin header.
In the Cookie section, you can include cookie names and their values, and check the presence of another cookie.
In the Host section, you can select Use original host and Resolved host.
In the User section, you can select Device type, Country, and Language.
As can be seen above, any plan level can opt to Enable query string sort, something that is only available to Enterprise Plan if enabled in the Cloudflare dashboard. This documentation actually does have a link that points to the old documentation reflecting this limitation.
And why should users trust the old documentation better than the new one? Aren’t both “explicitly documented”? Shouldn’t the new be considered to have superseded the old?
Cloudflare would do well to update its documentation to reflect its new products in a clear and unequivocal way. But if I’m wrong (and therefore the new documentation is wrong) and this is in fact a bug as the OP fears, then Cloudflare would need to update not only the documentation, but several aspects of its core product, as right now (ever since Cache Rules were launched, actually) the features discussed here can be enabled by users of any plan level.