Remote image fetch returns 404 with my cloud name

Justin Smith

January 10, 2021 15:18

Attempting to remotely fetch an image with my cloud name returns a 404:

https://res.cloudinary.com/ilo/image/fetch/f_auto,c_limit,w_3840,q_auto/https%3A%2F%2Fimages.prismic.io%2Filo-voices%2F303369ee-7b88-4237-ae0c-96f154ec7499_Paola%2Bleads%2Ba%2Bcooking%2Bclass.jpg%3Fauto%3Dcompress%2Cformat%26rect%3D0%2C0%2C1800%2C1013%26w%3D1280%26h%3D720

X-Cld-Error: Resource not found

However, the same image works fine using demo as the cloudname

https://res.cloudinary.com/demo/image/fetch/f_auto,c_limit,w_3840,q_auto/https%3A%2F%2Fimages.prismic.io%2Filo-voices%2F303369ee-7b88-4237-ae0c-96f154ec7499_Paola%2Bleads%2Ba%2Bcooking%2Bclass.jpg%3Fauto%3Dcompress%2Cformat%26rect%3D0%2C0%2C1800%2C1013%26w%3D1280%26h%3D720

 

 

1

• 

  Michal Kuperman

  January 11, 2021 09:39

  Hi Justin,

  For security reasons, the `fetch` resource type is restricted by default.

  There are two options you can use to resolve this:

  * Navigate to your settings page -> security tab, and remove the checkbox that restricts the 'fetch' type (under "Restricted media types"), then save the settings.

  * Use our SDK to create a signature for the URL or use the API to request that image is fetched, either of which indicates that the request came from your code and will allow the fetch to proceed.

  0
• 

  Daniel K.

  March 30, 2021 10:15

  How long does it take for the settings change in option 1 to take effect after pressing "Save"?

  I am having the exact same problem, and the suggested solution doesn't seem to work.

   

  0
• 

  Stephen Doyle

  March 30, 2021 14:20

  Hi Daniel,

  The settings change should be near-immediate, though if you were repeatedly accessing the failing URL, an error may be cached in our CDN for up to 24 hours. If that doesn't explain it, can you check the `x-cld-error` header of the response, perhaps something else is causing the failure in your case, like the remote URL not being available or the remote server responding to us with an error. If you don't want to share the example URL here, you can open a request for our support team directly

  Regards,

  Stephen

  0
• 

  Daniel K.

  March 31, 2021 08:22 Edited

  Hello Stephen, thanks for pointing it out; the cache problem does indeed explain the issue. After changing the settings, my original URLs were still failing, but I was indeed able to get images from the CDN for new URLs, including URLs with different sizes of the same original image. I am glad that this is now clarified, but I think the cache should really be invalidated after a settings change; if that is no option, a hint on the settings page that changes may need up to 24 hours to apply would probably help beginners to get started more easily.

  1
• 

  Daniel K.

  April 01, 2021 13:39 Edited

  Hi again Stephen,

  sorry for bothering you again, but the settings hasn't worked out, even 24 hours later I still can't get images from the CDN. My settings are as follows:

  

  As you can see, I have restricted the Fetch API and whitelisted the images.ctfassets.net domain, but the following link is still not working:

  https://res.cloudinary.com/tonies/image/fetch/f_auto,q_auto,w_300/https://images.ctfassets.net/l6vo76cztcax/7GcD9JSZoYpFmf6oPsM1PC/16b3098fbeebe7218734ae96f6c17d9c/accessories.jpg

  With "demo" as cloud name however, the same link shows the expected image.

  Any advice? Thanks.

  0
• 

  Stephen Doyle

  April 01, 2021 14:29

  Hi Daniel,

  The checkbox being filled means that the type is 'restricted', so assets of that type can only be accessed with a signature or created programmatically via the API. Apologies if you mentioned that that specifically and I missed it, but to clarify: checked = restricted, unchecked = publicly-accessible.

  The text box further down the same page marked "Allowed fetch domains:" is a separate/parallel configuration option. When fetching remote images is allowed, you can use that field to limit the URLs that can be fetched (note that you also still use the API or a signature to override that list of domains if needed, the limitation is for unauthenticated requests)

  Regarding the CDN cache, the issue with purging the cache 'early' is that for failed requests we don't have any identifier that can be referenced and used as the invalidation criteria (i.e there's no entry in your account's database for images that don't exist for us to look up to know which URLs should be invalidated). It's also relatively unusual that a 400 or 404 error is later fixed and becomes a successful response, so we need to cache those as long as possible for performance reasons. That said, if you contact us with the details of any image URLs that are still showing a cached response after the error was resolved, we can clear them manually for you 

  Thanks,

  Stephen

  0

Post is closed for comments.