Unexplainable 404s for Uploaded Images

Comments

7 comments

  • Avatar
    Andreas

    The problem seems to affect specific folders only. I created a new folder called test, below the root, uploaded an image and it works properly. Same if uploading something into the images folder below the root.

    Uploaded another file to the images/otherfolder folder as above and it fails. I have another folder called images/sharedBackgrounds and it fails too.

    Very strange.

    Andy

    0
    Comment actions Permalink
  • Avatar
    Andreas

    I did one more test and created a new images/level2 folder same problem.

    Is it possible that I cannot have sub-folders below a folder called images for some reason?

    Andy

    0
    Comment actions Permalink
  • Avatar
    Andreas

    It's not related to the folder name and happens to any new folder created. :(

    0
    Comment actions Permalink
  • Avatar
    Andreas

    Did some more tests with a folder called "css"  and downloading images without version from there get 400s instead of 404. Very confusing.

    This one for example: https://res.cloudinary.com/djbpaahbt/css/iii_vaf8du.jpg 

    With version it works:https://res.cloudinary.com/djbpaahbt/image/upload/v1621714261/css/iii_vaf8du.jpg 

    0
    Comment actions Permalink
  • Avatar
    Aleksandar Kostadinov

    Hi Andy,

    The reason the following URL (https://res.cloudinary.com/djbpaahbt/images/otherfolder/blah.jpg) returns an error is that 'images' is used as part of a feature called Dynamic SEO suffixes which allows you to replace the 'resource_type' and 'type' parameters if they are the default values (image/upload) with just 'images' and also set custom text between the public_id and extension as what we call an SEO suffix. The standard URL would have both 'resource_type' and 'type as part of the URL. Since you have your folder called 'images', it causes our URL parsing to interpret it as if you're trying to use Dynamic SEO suffixes and the 'images' is not interpreted to be part of the public_id hence the 404.

    You can resolve this by either:

    1. Adding the 'resource_type' (image) and 'type' (upload) parameters to the URL such as -https://res.cloudinary.com/djbpaahbt/image/upload/images/otherfolder/blah.jpg - we would then know to parse the 'images' as part of the public_id rather than interpret it as a special keyword.
    2. You can include the version number. Our system would then know that anything after the version number is the public_id. You can either use the full version or just a 'v1' - https://res.cloudinary.com/djbpaahbt/v1/images/otherfolder/blah.jpg

    In terms of the second example - https://res.cloudinary.com/djbpaahbt/css/iii_vaf8du.jpg - this doesn't work because 'css' is actually a previously valid value for 'resource_type' so when it's right after the cloud_name it gets interpreted as 'resource_type'. This then means the following value (iii_vaf8du) gets interpreted as a 'type' and since this is not a valid 'type' you get 400 here. You can resolve this case using the same two options from above: https://res.cloudinary.com/djbpaahbt/image/upload/css/iii_vaf8du.jpg or https://res.cloudinary.com/djbpaahbt/v1/css/iii_vaf8du.jpg

    0
    Comment actions Permalink
  • Avatar
    Andreas

    Thanks a lot Aleksandar for looking into this. Seems like this is not my lucky day picking bad folder names twice in a row. So I think the easiest solution would then be for me to not call a folder images and css and simply use some other folder name. :)

    0
    Comment actions Permalink
  • Avatar
    Aleksandar Kostadinov

    You're welcome.

    You can use those folder names, but you will want to also include the 'resource_type' and 'type' values in the URL. In this case, they are the default 'image/upload' so if your folder names were different you can access them without including the 'resource_type' and 'type'. E.g. https://res.cloudinary.com/demo/samples/animals/three-dogs.jpg from our demo account which I've omitted 'image/upload'. However, if you were to upload an asset with a different 'resource_type' (e.g. video) or you upload your resources with a different 'type' (e.g. private or authenticated) then you will need to include those as part of the URL otherwise we will default to using 'image/upload' and that will mean we won't be able to find the expected public_id.

    0
    Comment actions Permalink

Please sign in to leave a comment.