Why doesn't the image include the "Expire" header?

All of Cloudinary delivered images have the correct expiration headers using the Cache-Control 'max-age' directive (which is the best practice for CDN delivery).

Have more questions? Submit a request

Comments

  • Avatar
    John Bachir

    Could you elaborate on why it is best practice?

    Without Expires, browsers will keep asking cloudinary/akamai if the file has changed based on Last-Modified and Etag.

    Since the version ("v1386214311") updates when a new image is uploaded, this should be a perfectly attainable behavior for Cloudinary.

    The only thing I can think of that you might be guarding against is if your transformation algorithms change, or you introduce a bug, and you want to make sure the user gets the newest version. If that's the case, it would be nice to see this explained explicitly.

  • Avatar
    John Bachir

    Hmm, now I am doing some more research and folks claim that Cache-Control should be sufficient and achieve what I have described. That's not what I observed in my casual tests in my browser, but maybe I was misreading the chrome dev tools info.

  • Avatar
    Venky Rao

    I am having the same problem - I am not seeing the browser cache any of the images served up from Cloudinary. Any inputs on how I can change this?

  • Avatar
    Anthony Morgan

    Yeah, this is a deal breaker for me. We've a bunch of galleries that wait for images loaded before displaying and those requests are slowing down display time significantly. The images are already hashes so I'm not worried about modification. I'd like a way to specify that in the fetch url.

  • Avatar
    Ilya

    Same for me... Devtools status shows 200 instead of 304 (not modified/cahed). I can understand that it might be related to tracking/pricing on your side, but cashing is very important for us as well.
    Is there anyway that I can enable it in the dashboard?

Powered by Zendesk