Cache-control headers on R2 buckets, allowed or problematic?

Situation:
I’m currently experimenting with the R2 buckets and have exposed it through a worker binding. Our content will mainly exist of video files and we’re NOT on the enterprise plan.

Because of the fact that we use videos that likely get re-used over the span of a few days, I’d like to use cache-control headers so the browser doesn’t have to fetch them every single time. However I’ve been burned by this in the past

Backstory:
We currently host our videos at a different Object Store and I had put Cloudflare in front of it in order to get https on it. (Long story, the Object Store we use does have https, but on ugly urls, they support aliases with pretty names, but not https on those). I then put a Cloudflare worker on it to add CORS headers (something our Object Store didn’t seem to support back then, I’ve since figured out how to do it), and figured I’d add cache-control headers whilst I was at it. This resulted in Cloudflare caching the videos => Which promptly got us temporarily knocked off of Cloudflare because that’s a violation of “storage or caching of non-HTML content, such as video or audio files” is not allowed unless that’s agreed upon in the terms of the enterprise plan.

Question
Now my question is: Will I run into the same issues when using the R2 workers and setting a cache-control header on the response as follows: headers.set("cache-control", "public, max-age=259200)? Or will I have to use private to make sure I don’t run into the same issues?