The f_auto feature works at the CDN level based on the specific browser. So for this to work, Cloudinary needs to prevent caching of the response of the URL by proxies along the way from the CDN to the browser. That's why private is needed. public is always added by the CDN. As defined by the standard and respected by proxies, the private flag "wins", therefore it's OK to have them both.
Why does the Cache-Control header contain both 'public' and 'private'?
Comments
3 comments
So in case that f_auto is specified, no images are cached in edge servers, every single request from web browsers hits the Cloudinary image server, which could reside in US?
I mean that most of our users are from Japan, so every traffic rounds trip the pacific ocean?
Hi Takashi,
No worries, the requests are cached on the CDN itself after the f_auto directive converts into the equivalent best-format per browser URL. For example, assuming the request was made via a Chrome browser, most likely a WebP image will be returned, so the https://res.cloudinary.com/cloudname/image/upload/f_auto/sample.jpg will actually be converted on the CDN to https://res.cloudinary.com/cloudname/image/upload/f_webp/sample.jpg and this URL will indeed be cached on the CDN. Further requests https://res.cloudinary.com/cloudname/image/upload/f_auto/sample.jpg from Chrome will return the cached WebP image that is returned when converting the URL to https://res.cloudinary.com/cloudname/image/upload/f_webp/sample.jpg behind the scenes.
The `private` attribute in the Cache-Control header is only intended for directing other proxies along the way to avoid caching the URL as well, so the functionality of the `f_auto` algorithm on the CDN won't be unintentionally interfered.
I hope this makes sense. Please let me know if anything requires further clarification.
Best,
Raz
I see. The url is tweaked and then used as a key to the image. I got it.
Please sign in to leave a comment.