Why does the Cache-Control header contain both 'public' and 'private'?

Follow

Comments

3 comments

  • Avatar
    Raz Ziv

    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 

    0
    Comment actions Permalink
  • Avatar
    Takashi Futada

    I see. The url is tweaked and then used as a key to the image. I got it.

    0
    Comment actions Permalink
  • Avatar
    Takashi Futada

    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?

    0
    Comment actions Permalink

Please sign in to leave a comment.