I'm getting a 404 ("not found") for my transformed image while other versions of that image work

404 errors are cached in an exponential back-off manner. If the transformed image is accessed before the original is loaded, the system returns 404 and this returned 404 error is cached, first for 1 minute, and the cache period doubles every time until settling on a maximum 24-hour cache period. If you upload the original after the transformed image is cached, you need to wait for the cache to expire for the transformed image to appear, or use a different transformation.

Other transformed images that were first accessed after the original was uploaded will work as expected. In other words, please make sure the original image is fully uploaded to your Cloudinary account before attempting to access any of its transformed image's URLs.

Other errors beside 404's are cached in a similar manner.

Have more questions? Submit a request

Comments

  • Avatar
    XO Group Inc.

    has anyone got a resolution to this? we're seeing it too

  • Avatar
    Itay Taragano

    Any error status code, including '404 Not Found' is cached for 1 hour for safety reasons. This means that after a full hour is passed, Cloudinary's service will be accessed for trying again to generate and deliver the requested image.

    Trying to access a derived image of a non existing public ID will result with a 404 status code that would be cached for an hour.

  • Avatar
    Aaron Craig

    While that is an answer, it's not really a solution, is it?

    That means that if there's a race condition or some other issue on Cloudinary's side that causes a 404 to be returned in error, the calling site will not be able to display the correct image size for an hour?  Also, that means the calling service gets an incorrect 404 error for an hour, which is doubly unfortunate.

  • Avatar
    Aaron Craig

    It also seems that the wrong 404 error is not cached if you try to access the image through the Cloudinary control panel.

    So, if an image (I'm using o8ix3qswdks9tdvfvrzp) gives a 404 on my server, going to the Media Library and searching for 'o8ix3qswdks9tdvfvrzp' returns the image.

    I'm using the Ruby library and the Cloudinary::Api.resource(image_id) method.

    It would be uber-awesome to sort this out :)

  • Avatar
    Itay Taragano

    Hi Aaron,

    Thank you for your comments. I apologize for the confusion.

    Trying to access the original resource (not a derivative) will return 404 only if it's currently deleted. The 404 is not cached in this case .

    The only issue is with accessing derived resources of non-existent resources. This is also not a race condition. This only happens when a derived resource is accessed before the upload call returns. Once the upload call returns, Cloudinary shouldn't have such errors.

  • Avatar
    Aaron Craig

    Thanks for getting back on this.

    Then my specific case is more troublesome.  I am occasionally getting 404 errors on the original resource, not a derivitave.  From my example above, in my Rails application, a call like:

    Cloudinary::Api.resource('o8ix3qswdks9tdvfvrzp')

    returns a 404 from the API, but going to the Media Library UI on your site and searching for 'o8ix3qswdks9tdvfvrzp' returns the image. 

     

    Any thoughts?

     

     

  • Avatar
    Itay Taragano

    Hi Aaron,

    Your file indeed exists, and should be returned correctly when calling 'Cloudinary::Api.resource('o8ix3qswdks9tdvfvrzp')'.

    Are you still getting this error now? In our logs we didn't see any 404s for your account. However, we did see several 420s (rate limited). Could this have been the error your got?

    Please note that by default Admin API calls are rate limited to 500 per hour (12,000 daily).

    Looking forward for your response.

  • Avatar
    Aaron Craig

    Yes, that sounds likely.  I'll investigate.  Thanks for getting back on this.

  • Avatar
    Warranteer Digital ltd.

    Hello,

    I'm trying to fetch and transform an image, and i'm getting a 404 and the header:
    X-Cld-Error: Resource not found - Error in loading <img_url> - HTML response.

    I have no problem opening the image (with the img_url) in my browser.

    What could be the problem here?

    Thanks!

    p.s.
    The image is hosted in google's cloudstorage

  • Avatar
    Richard Gieg

    Hi Warranteer Digital Team,

    I apologize for the delay in my response. Are you still noticing this issue? If so, would you be able to share the URL for this particular image so we can try reproduce the problem on our end?

  • Avatar
    Siphiwe

    Good day. I've got this same issue. One of the images is https://res.cloudinary.com/afroswag/image/upload/b_white,c_limit,e_saturation:50,r_5/a_0,q_auto/v1/vendors/botlefela/products/Newborn_crochet_shoes_assorted.jpg. I thought the issue was spaces but after replacing them with underscores I still get "x-cld-error:Resource not found - vendors/botlefela/products/Newborn_crochet_shoes_assorted"

    I must add that all the images were working until I recently rebuilt the database where the image public id's are stored. On the front end, the url looks correct (to the naked eye). Please do assist. Thanks a lot

  • Avatar
    Roee Ben-Ari

    Hi Siphiwe, I see a valid image on https://res.cloudinary.com/afroswag/image/upload/b_white,c_limit,e_saturation:50,r_5/a_0,q_auto/v1/vendors/botlefela/products/Newborn_crochet_shoes_assorted.jpg. To make sure, I've manually invalidated this resource. Let us know if it works well now?

  • Avatar
    Siphiwe

    Hi Roee. Thanks for your assistance. Is there a requirement for public id's not to have spaces (or forward slashes) by any chance? I renamed the rest of the problematic images and they became visible. Also, the faulty image id's had additional (non-ascii) characters which I hadn't entered.

  • Avatar
    Roee Ben-Ari

    While '?\%<>' are utterly forbidden, other special characters will be replaced with underscores '_' and preceding/trailing occurrences will be trimmed. Forward slashes are allowed (you can definitely have folders in your public_id) and while whitespaces are allowed as well, we recommend avoiding it.
    Other than that, the public ID should not begin nor end with whitespace or forward-slash (those will be omitted as well).

Powered by Zendesk