Entity decoding in URLs causing 404s

Andrew Pile

January 24, 2020 20:36 Edited

Hi-

 

I'm trying to cache this image: https://megaphone-prod.s3.amazonaws.com/podcasts/ae629f74-fa11-11e6-b53b-9fe143e07991/image/uploads_2F1556691633720-3ipbikwxws2-ad53482b076e97f5379da96d5a83ab02_2FFamily%2BGhost%2BLogo%2B9.0.png

 

However the url-encoded spaces ("%2B") appear to be being decoded to "+" by Cloudinary during the fetch. Here's what I can decipher from the request headers:

----

curl -I https://res.cloudinary.com/gumball/image/fetch/q_auto:best,dpr_2.0,f_auto,g_north,c_fill,fl_force_strip,w_500/https://megaphone-prod.s3.amazonaws.com/podcasts/ae629f74-fa11-11e6-b53b-9fe143e07991/image/uploads_2F1556691633720-3ipbikwxws2-ad53482b076e97f5379da96d5a83ab02_2FFamily%2BGhost%2BLogo%2B9.0.png
HTTP/2 404
content-disposition: inline
content-transfer-encoding: binary
content-type: image/gif
expires: Fri, 24 Jan 2020 20:20:06 GMT
x-cld-error: Resource not found - https://megaphone-prod.s3.amazonaws.com/podcasts/ae629f74-fa11-11e6-b53b-9fe143e07991/image/uploads_2F1556691633720-3ipbikwxws2-ad53482b076e97f5379da96d5a83ab02_2FFamily+Ghost+Logo+9.0.png
x-request-id: 5e0294949ee4c3d98f02bc5096f46d3c
date: Fri, 24 Jan 2020 20:19:06 GMT
vary: Accept,User-Agent
strict-transport-security: max-age=604800
cache-control: private,
server-timing: cloudinary;dur=446;start=2020-01-24T20:19:06.424Z,cld-id;desc=5e0294949ee4c3d98f02bc5096f46d3c,cld-error;desc="Resource not found - https://megaphone-prod.s3.amazonaws.com/podcasts/ae629f74-fa11-11e6-b53b-9fe143e07991/image/uploads_2F1556691633720-3ipbikwxws2-ad53482b076e97f5379da96d5a83ab02_2FFamily+Ghost+Logo+9.0.png",fastly;dur=0;total=455;start=2020-01-24T20:19:06.418Z;desc=MISS,rtt;dur=24
server: Cloudinary
timing-allow-origin: *
access-control-allow-origin: *
access-control-expose-headers: X-Cld-Error,Content-Length,Content-Disposition,Server-Timing,Vary
accept-ranges: bytes
content-length: 0

----

 

As you can see Cloudinary appears to be requesting "...Family+Ghost+Logo+9.0.png" not "Family%2BGhost%2BLogo%2B9.0.png". Obviously it's bad practice to have urlencoded entities like this in a file name, but in this case it's out of our control. Shouldn't Cloudinary respect the original URL encoding when using the '/fetch' API?

0

• 

  Aleksandar Kostadinov

  January 25, 2020 19:14

  Hi Andrew,

  In general, we always recommend URL encoding either the relevant characters such as +, ? or the whole remote URL.

  For example, in this case, encoding only the %2B to %252B:

  https://res.cloudinary.com/gumball/image/fetch/q_auto:best,dpr_2.0,f_auto,g_north,c_fill,fl_force_strip,w_500/https://megaphone-prod.s3.amazonaws.com/podcasts/ae629f74-fa11-11e6-b53b-9fe143e07991/image/uploads_2F1556691633720-3ipbikwxws2-ad53482b076e97f5379da96d5a83ab02_2FFamily%252BGhost%252BLogo%252B9.0.png

  Or the whole URL:

  https://res.cloudinary.com/gumball/image/fetch/q_auto:best,dpr_2.0,f_auto,g_north,c_fill,fl_force_strip,w_500/https%3A%2F%2Fmegaphone-prod.s3.amazonaws.com%2Fpodcasts%2Fae629f74-fa11-11e6-b53b-9fe143e07991%2Fimage%2Fuploads_2F1556691633720-3ipbikwxws2-ad53482b076e97f5379da96d5a83ab02_2FFamily%252BGhost%252BLogo%252B9.0.png

  I would recommend the second approach as you won't need to watch out for any special characters that you have not accounted for initially.

  Best regards,

  Aleksandar

  0
• 

  Andrew Pile

  January 27, 2020 19:24

  This worked! Thanks for the quick response.

  0

Post is closed for comments.