That won't be enough. I tested it before. We have to encode the url (usually in base64), otherwise many images will simply fail to load. It's a mess. I gave up back them because it was creating more problems than solutions. It was common for the proxy to fail and the user would blame us for not showing the image correctly (censorship! 🙄)
mmmmm, this is quite complicated when it comes to standardized proxy API.
But if you don't want to get overwhelmed, Try to do the classic %s thingy:
```
https://www.example.com/?url=%s
```
And then let the user decide.
There are some numerous image compression services out there so it should not be hard for client.
Discussion
Well, better not encode the URL to base64.
Try do something like encodeURIComponent() instead:
```
> encodeURIComponent("https://google.com") 'https%3A%2F%2Fgoogle.com'
```
You may add a switch to "request directly on failure" for that case.
[Still it may be useful for certain end users as compressor proxies are self host-able nowadays like https://github.com/Yonle/bandwidth-hero-proxy (for Bandwidth Hero browser addon)]
Yep we tested the basic url encoder with imgproxy for 4 months last year. Things would break so much that I had to move to their base64 version of it. Then I discovered that half of the formats weren't getting reduced in size and gave up :(
It has to be something that works 100% of the time and when it doesnt, there has to be a way to alert the user that their proxy service sucks. Otherwise, it's going to rain complains on our emails.
We probably need to teach people to add a caching server or a CDN in front of the proxy, otherwise processing compressions can get really expensive, even for single user servers.
Especially for country under censorship，for instance,China.
It's always depending on their services. Yep. Could admit tho.
Wouldnt be better if a third party proxy app intercepted all app communications and made images go to their own proxy server?
