Open ginoliang1130 opened 5 days ago
Hey @ginoliang1130!
Sorry, I can't quite understand, why you double-encode your URLs.
Hi @DarthSim,
To clarify, the first link is experiencing a double encoding issue: the % symbol in the URL has been encoded twice, appearing as %25, which prevents the link from being accessed.
In an ideal scenario, it should function like the second URL. We’re currently investigating internally to pinpoint the root cause, which includes reviewing our code for any irregular encoding.
Additionally, we’re reaching out to the community to see if anyone has encountered a similar situation.
Thanks.
To clarify, the first link is experiencing a double encoding issue: the % symbol in the URL has been encoded twice, appearing as %25
Yes, I understand what's happening. I can't understand why you do that. You don't need to escape it twice. I believe the filename in your storage is 03-第二波連載活動.jpg
. So you naturally need to escape it to put it in a URL. But you don't need to escape it twice.
In an ideal scenario, it should function like the second URL
This would break cases like this.
I'm closing this issue since imgproxy acts 100% correctly in this case.
In the current version, there is an issue with URL encoding.
For instance, compare the following URLs:
https://img.dev.kadokado.me/insecure/s:128/plain/ownerId/3/cover/77aa7c5e0324552a1a6713f1e4d8f60b/03-%25E7%25AC%25AC%25E4%25BA%258C%25E6%25B3%25A2%25E9%2580%25A3%25E8%25BC%2589%25E6%25B4%25BB%25E5%258B%2595.jpg
In this URL, the % symbols are double-encoded (represented as %25), which makes it inaccessible.
https://img.dev.kadokado.me/insecure/s:128/plain/ownerId/3/cover/77aa7c5e0324552a1a6713f1e4d8f60b/03-%E7%AC%AC%E4%BA%8C%E6%B3%A2%E9%80%A3%E8%BC%89%E6%B4%BB%E5%8B%95.jpg
This URL is encoded once, so it is accessible as expected.
Both URLs point to the same storage file path, so ideally, the URL should be accessible with a single encoding, not double encoding. When a URL is encoded once, it should work as expected, but in my case, the issue arises when it gets incorrectly handled as though it were encoded twice, causing it to be inaccessible.
Has anyone else encountered this issue?
I reviewed this issue, and while it is similar, my problem is the opposite. The issue in question discusses cases where the % character gets double-encoded, leading to inaccessible URLs. In contrast, my problem involves URLs where % is encoded only once, but this causes issues with accessing the image as well.
REF.https://github.com/imgproxy/imgproxy/issues/1298
Thanks.