Remove cached images (by API/manual) [15774949]

Submitted by Eugene Huseynov on 23-8-2016 0:00:00
24 votes on UserVoice prior to migration

Given

Image source (url parametre) is: https://maps.googleapis.com/maps/api/staticmap?sensor=false&size=2048x350&scale=2&maptype=roadmap&zoom=13&markers=color:blue|size:small|1400+Oakton+Street,+Evanston,+IL+60202

Encoded version: maps.googleapis.com%2Fmaps%2Fapi%2Fstaticmap%3Fsensor%3Dfalse%26size%3D2048x350%26scale%3D2%26maptype%3Droadmap%26zoom%3D13%26markers%3Dcolor%3Ablue%257Csize%3Asmall%257C1400%2BOakton%2BStreet%2C%2BEvanston%2C%2BIL%2B60202

I'm using following images.weserv.nl parameters: &w=70&t=square&h=70
Final link: http://images.weserv.nl/?url=maps.googleapis.com%2Fmaps%2Fapi%2Fstaticmap%3Fsensor%3Dfalse%26size%3D2048x350%26scale%3D2%26maptype%3Droadmap%26zoom%3D13%26markers%3Dcolor%3Ablue%257Csize%3Asmall%257C1400%2BOakton%2BStreet%2C%2BEvanston%2C%2BIL%2B60202&w=70&t=square&h=70

Issue

Some of the "google map images" cached properly, some of them is not (link provided above - final link)
Looks like when caching process is broken by any internal reason, the "image url" is still remembered as a key in your collection. So there is no way to rebuild correct cache for that "broken" image.

Question

Is any api/way to expire/delete/rebuild/invalidate existing image cache?

Response

by Andries Louw Wolthuizen on 23-8-2016 0:00:00

Need to check if there is a reliable way to remove images from all caches. Will look into this!

Comments

Comment by Eugene Huseynov on 30-8-2016 22:39:00

Hi Andries.

I appreciate for your time and energy you spend for this project.

Any luck to fix such king issues or may be add an API for the project so customers could reset/update/delete cached images themself?

Thank you one more time.

Eugene

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 1-9-2016 18:53:00

Hi Eugene,

This project didn't start with the intent of providing access to reset/update/delete images. To serve all users, there are caches at multiple levels involved (edge, processing, backplanes, requesters). The difficulty is that not all of these caches are capable of reliable removing single entries, and the freshness is also varying wildly (based on effort to recreate, the number of requests, etc, etc).

However, the feature as proposed is still on the roadmap, and will probably be implemented in the next code-refresh. When this will be finished is uncertain, as many new features and changes are to be incorporated in such an update.

In the meanwhile, you could consider using our code to set up your own solution. The GitHub-repo is sans any cache, so you should extent it with your own caching solution, or disregard it completly. For starters I would advise some form of reverse caching proxy (like nginx).

--
Andries

Original UserVoice Submission

Supporting IPv6 [2478866]

Submitted by Andries Louw Wolthuizen on 29-12-2011 0:00:00
0 votes on UserVoice prior to migration

Original UserVoice Submission

image bug [2624073]

Submitted by sinz on 24-2-2012 0:00:00
1 votes on UserVoice prior to migration

http://images.weserv.nl/?url=4.bp.blogspot.com/-OolsZerGQ7Q/TvhWw7lwiuI/AAAAAAAAAmM/-vxLDJulH_k/s72-c/nike-just-do-it.jpg&w=120&h=120&t=square
http://images.weserv.nl/?url=4.bp.blogspot.com/-OolsZerGQ7Q/TvhWw7lwiuI/AAAAAAAAAmM/-vxLDJulH_k/s72-c/nike-just-do-it.jpg&w=60&h=60&t=square

Response

by Andries Louw Wolthuizen on 19-3-2012 0:00:00

I don’t see any problem here, can you describe the issue?

Original UserVoice Submission

Add Pricing info [2813884]

Submitted by tlianza on 1-5-2012 0:00:00
1 votes on UserVoice prior to migration

Your service matches exactly what I'm looking for, but I'm unclear if it's a business I can rely on, or a project that's for fun. If the former, what is the pricing/terms? If the latter, is the code open source by chance?

Response

by Andries Louw Wolthuizen on 15-7-2012 0:00:00

The image proxy is free for use to anyone, and we offer it as-is, it’s just basic image resizing, available to anyone, easy to use. We try to keep everyone as happy as we can.
We, as a company, make websites, web applications and mobile applications, so the image proxy is used by us and our customers a lot. By making it freely available, we gain some experience with different user cases, and our customers appreciate it too! It’s a service towards our customers, and relations of our customers. We partner with other companies in our industry, and they see the image proxy as a timesaving solution in their projects too. It’s saving us traffic (through compression), and offloading our main servers, because customers don’t have to use poor self-written scripts for image resizing, instead, they can direct it to images.weserv.nl, which is dedicated to the task. Operating costs of the image proxy are very low for us, the traffic is already paid for (we operate our own gigabit uplinks). We intend to keep the service running for many years to come.
Try it for yourself, if you experience problems or if it doesn’t meet expectations, mail us.
If you’re however interested in running the source code yourself, and use the service internally, please e-mail me on postmaster at weserv dot nl. The code isn’t open source, as in, open for everyone, but we do let company’s run it internally, which is evaluated on a case-by-case basis. The whole system is written in PHP, uses an file-based caching system, and on top of that utilizes normal HTTP reverse proxy’s to perform well under excessive load.
I hope to have answered your question.

Comments

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 1-5-2012 17:23:00

The image proxy is free for use to anyone, and we offer it as-is, it’s just basic image resizing, available to anyone, easy to use. We try to keep everyone as happy as we can.
We, as a company, make websites, web applications and mobile applications, so the image proxy is used by us and our customers a lot. By making it freely available, we gain some experience with different user cases, and our customers appreciate it too! It’s a service towards our customers, and relations of our customers. We partner with other companies in our industry, and they see the image proxy as a timesaving solution in their projects too. It’s saving us traffic (through compression), and offloading our main servers, because customers don’t have to use poor self-written scripts for image resizing, instead, they can direct it to images.weserv.nl, which is dedicated to the task. Operating costs of the image proxy are very low for us, the traffic is already paid for (we operate our own gigabit uplinks). We intend to keep the service running for many years to come.
Try it for yourself, if you experience problems or if it doesn’t meet expectations, mail us.
If you're however interested in running the source code yourself, and use the service internally, please e-mail me on postmaster at weserv dot nl. The code isn't open source, as in, open for everyone, but we do let company's run it internally, which is evaluated on a case-by-case basis. The whole system is written in PHP, uses an file-based caching system, and on top of that utilizes normal HTTP reverse proxy's to perform well under excessive load.
I hope to have answered your question.

Comment by Anonymous on 23-8-2015 1:47:00

thanks

Original UserVoice Submission

Custom domain [15107112]

Submitted by Anonymous on 7-7-2016 0:00:00
1 votes on UserVoice prior to migration

Allow us to setup a custom domain, such as images.example.org I understand this would be hard to implement but I would pay for this too.

Response

by Andries Louw Wolthuizen on 12-7-2016 0:00:00

Please see https://github.com/andrieslouw/imagesweserv/wiki/CNAME-ing-your-(sub)domain-to-images.weserv.nl

Original UserVoice Submission

Add a "Scale to Fill" resize feature [2834089]

Submitted by tlianza on 8-5-2012 0:00:00
1 votes on UserVoice prior to migration

The service is fantastic and it may be the case that no one thus far is in need of this, but one thing we do at http://www.wishpot.com/ is crop images in such a way that they fill a rectangle, even if that means we have to cut out part of the image (via overflow:hidden in css).
Unlike a normal resize, where you'd set a maximum height and width, what this code does is pick the smallest dimension and make that the height or width of the box. Then, we'll overflow the larger dimension.
For example, to fit an image into a box that's 100h x 50w, if the image is 300h x 200w, we'd make the height 100px, which would make the width 66px. The height would then fit perfectly in our box, and the width would be a little too wide, in which case we just center it and crop off the sides.
As a result, if you're okay with loosing some data, you're able to fill an area completely.

Response

by Andries Louw Wolthuizen on 14-6-2012 0:00:00

Please see the &t=square option, if you feed it an image which is 300h, 200w, and request it like:
http://images.weserv.nl/?url=http://host/dir/image-300h-200w.jpg&t=square&h=100&w=50
It will return the image which is 100×50 centered, and cropped of the sides.
No need to do such things yourself in CSS.
If you want to center it in CSS yourself, use &t=fit (or don’t use any &t=), and only give the height you want.
Example: http://images.weserv.nl/?url=http://host/dir/image-300h-200w.jpg&h=100
This should give you an image of 100×66, which you can center yourself in CSS.
Let me know if there’s still any need for an t=fill option.

Comments

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 8-5-2012 14:55:00

Please see the &t=square option, if you feed it an image which is 300h, 200w, and request it like:
http://images.weserv.nl/?url=http://host/dir/image-300h-200w.jpg&t=square&h=100&w=50
It will return the image which is 100x50 centered, and cropped of the sides.
No need to do such things yourself in CSS.
If you want to center it in CSS yourself, use &t=fit (or don't use any &t=), and only give the height you want.
Example: http://images.weserv.nl/?url=http://host/dir/image-300h-200w.jpg&h=100
This should give you an image of 100x66, which you can center yourself in CSS.
Let me know if there's still any need for an t=fill option.

Comment by tlianza on 8-5-2012 20:08:00

That is AWESOME! Sorry, when I saw square, I had made the assumption that it could only produce square images. But, reading further I see what you're saying, and that you can pass it non-square dimensions. That's great.

Original UserVoice Submission

BUG: Redirecting the browser on facebook fbcdn links [4277688]

Submitted by wasabi on 7-8-2013 0:00:00
1 votes on UserVoice prior to migration

I've noticed when using weserv as a HTTPS wrapper, it somehow decides to redirect the browser which breaks the green lock (mixed content warning).
I suggest the default behavior is never to redirect the user.
Here is the link.
https://images.weserv.nl?w=800&t=fit&url=sphotos.ak.fbcdn.net/hphotos-ak-snc4/hs384.snc4/44769_153256218023587_100000176287891_503417_3448087_n.jpg

Response

by Andries Louw Wolthuizen on 11-10-2013 0:00:00

Added the parameter &fnr
Usage:
https://images.weserv.nl?w=800&t=fit&url=sphotos.ak.fbcdn.net/hphotos-ak-snc4/hs384.snc4/44769_153256218023587_100000176287891_503417_3448087_n.jpg&fnr
Or:
https://images.weserv.nl?w=800&fnr&t=fit&url=sphotos.ak.fbcdn.net/hphotos-ak-snc4/hs384.snc4/44769_153256218023587_100000176287891_503417_3448087_n.jpg
This forces all possible redirects to return error 404, no matter if you access the proxy over HTTPS or not.
Please let me know if you run into problems.

Comments

Comment by wasabi on 8-8-2013 13:54:00

Great... Thanks for the explanation.
I guess even a adding an optional query string like force-no-redirect=true would be helpful

Original UserVoice Submission

Add image compression!! [3386044]

Submitted by Uri Goldshtein on 25-11-2012 0:00:00
1 votes on UserVoice prior to migration

That will be a huge help!

Response

by Andries Louw Wolthuizen on 19-9-2013 0:00:00

What compression do you mean?
GZip compression is disabled, because it increases filesizes for JPEG-images, and it increases CPU-load on client and server.
JPEG-compression is honored, and the default compression when requesting BMP-images (they are converted to JPEG).
If you want to modify compression for JPEG-images, you can already do so by setting the &q= parameter, see: /archive/suggestion-2693320-add-a-parameter-to-define-the-compression-level
Please explain your question more accurate in the comments, thank you!

Comments

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 25-11-2012 16:24:00

What compression do you mean?
GZip compression is disabled, because it increases filesizes for JPEG-images, and it increases CPU-load on client and server.
JPEG-compression is honored, and the default compression when requesting BMP-images (they are converted to JPEG).
If you want to modify compression for JPEG-images, you can already do so by setting the &q= parameter, see: /archive/suggestion-2693320-add-a-parameter-to-define-the-compression-level
Please explain your question more accurate, thank you!

Comment by mon on 13-6-2013 5:52:00

Is JPEG compression avaliable.?If not ,Im wondering if this feature can be integrated with the support of JPEG compression component.http://www.rasteredge.com/how-to/csharp-imaging/jpeg2000-codec/

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 13-6-2013 11:14:00

We support JPEG-compression, and you can change the quality parameter of it.
However, JPEG 2000 is not something we can support, this codec is covered by patents, and not supported widely in libraries nor browsers.
There is however something we are considering; supporting Google's WebP format. This format allow substantial savings over JPEG-compression, and is more widely supported. We're waiting for support in general available libraries for WebP.
Another thing to consider is chosing the right filetype, right now the proxy honores the original filetype of the to-be-resized image. This may or may not be the optimal quality/size balance for images.

Comment by Donna on 29-10-2013 3:51:00

HI there
If you want to do the image compression,you can just add an image program like this :
http://www.rasteredge.com/how-to/csharp-imaging/image-compressing/
But i really appreciated Andries Louw Wolthuizen.Because i am looking for an image program which supports to modify compression for JPEG-images

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 1-11-2013 19:10:00

This proxy is coded in PHP, we don't have any knowledge about C# or the program you're linking to. You can already specify JPEG compression, by setting the &q= parameter.

Original UserVoice Submission

resize with get parameter image [3340674]

Submitted by sinz on 10-11-2012 0:00:00
1 votes on UserVoice prior to migration

how do i resize this image?
http://www.espnstar.my/servlet/file/867564_33_preview.jpg?ITEM_ENT_ID=867564&ITEM_VERSION=2&COLLSPEC_ENT_ID=10&FILE_SERVICE_CONF_ID=33

Response

by Andries Louw Wolthuizen on 15-11-2012 0:00:00

By url encoding all parameters:
http://images.weserv.nl/?url=www.espnstar.my/servlet/file/867564_33_preview.jpg%3FITEM_ENT_ID%3D867564%26ITEM_VERSION%3D2%26COLLSPEC_ENT_ID%3D10%26FILE_SERVICE_CONF_ID%3D33
Or, example with resizing:
http://images.weserv.nl/?url=www.espnstar.my/servlet/file/867564_33_preview.jpg%3FITEM_ENT_ID%3D867564%26ITEM_VERSION%3D2%26COLLSPEC_ENT_ID%3D10%26FILE_SERVICE_CONF_ID%3D33&h=100

Comments

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 10-11-2012 16:04:00

By url encoding all parameters:
http://images.weserv.nl/?url=www.espnstar.my/servlet/file/867564_33_preview.jpg%3FITEM_ENT_ID%3D867564%26ITEM_VERSION%3D2%26COLLSPEC_ENT_ID%3D10%26FILE_SERVICE_CONF_ID%3D33
Or, example with resizing:
http://images.weserv.nl/?url=www.espnstar.my/servlet/file/867564_33_preview.jpg%3FITEM_ENT_ID%3D867564%26ITEM_VERSION%3D2%26COLLSPEC_ENT_ID%3D10%26FILE_SERVICE_CONF_ID%3D33&h=100

Original UserVoice Submission

Error 404? [3616797]

Submitted by anonymouse on 3-2-2013 0:00:00
1 votes on UserVoice prior to migration

This url: statik.tempo.co/?id=164903 returns Error 404
Tried:
https://images.weserv.nl/?url=statik.tempo.co%2F%3Fid%3D164903
https://images.weserv.nl/?url=statik.tempo.co/?id=164903

Response

by Andries Louw Wolthuizen on 3-2-2013 0:00:00

Error resolved, cause unknown, seems like a bit fell over.

Original UserVoice Submission

[bug] blogspot image bug [2572791]

Submitted by sinz on 6-2-2012 0:00:00
1 votes on UserVoice prior to migration

i dont know all blogspot images will be all black if t=square
no problem if t=absolute
eg:
http://images.weserv.nl/?t=square&w=60&h=60&url=1.bp.blogspot.com%2F-K3KwoQUq90A%2FTy-Lt-N4feI%2FAAAAAAAADMA%2F1qVfxFFmvm8%2Fs72-c%2FUntitled%252B1.jpg
http://images.weserv.nl/?t=absolute&w=60&h=60&url=1.bp.blogspot.com%2F-K3KwoQUq90A%2FTy-Lt-N4feI%2FAAAAAAAADMA%2F1qVfxFFmvm8%2Fs72-c%2FUntitled%252B1.jpg

Response

by Andries Louw Wolthuizen on 6-2-2012 0:00:00

Thank you for noticing!
I just implemented an fix, it seemed that all images, where height == width, were affected by this problem. The issue seems solved here, do you still experience any problems?

Comments

Comment by sinz on 6-2-2012 12:43:00

works like charm.
thanks!

Original UserVoice Submission

Support non-standard ports. [13807617]

Submitted by John Doe on 11-5-2016 0:00:00
3 votes on UserVoice prior to migration

Accessing sites which listen to a non-standard HTTP port.

Response

by Andries Louw Wolthuizen on 11-10-2016 0:00:00

We looked into this problem, but there are too many pathways of abuse that would be opened, therefore, we’re not going to implement this.
Please use a reverse-proxy in front of your site (like Nginx), to translate to port 80 (http) or 443 (https).

Original UserVoice Submission

Add parameter to use progressive jpegs [3998911]

Submitted by Michal on 26-5-2013 0:00:00
1 votes on UserVoice prior to migration

Response

by Andries Louw Wolthuizen on 26-5-2013 0:00:00

I added the parameter &il
This will add interlacing to GIF and PNG. For JPEG it will add progressive rendering of the resulting image.
Example, normal:
http://images.weserv.nl/?url=upload.wikimedia.org/wikipedia/commons/e/e0/JPEG_example_JPG_RIP_050.jpg
Progressive:
http://images.weserv.nl/?url=upload.wikimedia.org/wikipedia/commons/e/e0/JPEG_example_JPG_RIP_050.jpg&il
If this is what you want, I will update the documentation on images.weserv.nl shortly.
Please let me know if there are any problems.

Comments

Comment by Michal on 26-5-2013 18:54:00

Wow. Yes, that's perfect, thanks.

Original UserVoice Submission

Error 404? [4039549]

Submitted by Anonymous on 7-6-2013 0:00:00
1 votes on UserVoice prior to migration

url 1: https://fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-frc3/486362_574580832586511_1342350572_n.jpg
url 2: http://fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-frc3/486362_574580832586511_1342350572_n.jpg
Error 404: https://images.weserv.nl/?url=ssl:fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-frc3/486362_574580832586511_1342350572_n.jpg
OK: https://images.weserv.nl/?url=fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-frc3/486362_574580832586511_1342350572_n.jpg

Response

by Andries Louw Wolthuizen on 7-6-2013 0:00:00

Sorry, someone made a coding error in handling SSL-connections, solved the error!
“?url=ssl:” should work again now!

Comments

Comment by Anonymous on 7-6-2013 21:59:00

Error detail:
Error 404: Server could parse the ?url= that you were looking for, error it got: Couldn't resolve host 'n-sphotos-h-a.akamaihd.net'
Also, if possible, please replace any occurences of of + in the ?url= with %2B (see + bug)
Comment:
As if the beginning of 'fbcdn-sphotos-h-a.akamaihd.net' is cut off by the length of 'ssl:'.

Comment by Anonymous on 7-6-2013 22:02:00

Much thanks! That was pronto.
Best wishes.

Original UserVoice Submission

If the images were modified, does the proxy will refresh it after a certain period of time? Thanks. [3153039]

Submitted by Spencer on 12-9-2012 0:00:00
1 votes on UserVoice prior to migration

If the images were modified, does the proxy will refresh it after a certain period of time? Thanks.

Response

by Andries Louw Wolthuizen on 15-11-2012 0:00:00

The proxy caches images in different ways, depending on the rate of requests, no more than 31 days, and at least 14 days. Most images refresh every 14 days.

Original UserVoice Submission

bug? [2640029]

Submitted by sinz on 1-3-2012 0:00:00
1 votes on UserVoice prior to migration

screenshot - http://i.imgur.com/D9GKn.png
actual image - http://i1214.photobucket.com/albums/cc482/mediamalaya/neelofa1.jpg
http://images.weserv.nl/?url=i1214.photobucket.com/albums/cc482/mediamalaya/neelofa1.jpg

Response

by Andries Louw Wolthuizen on 19-3-2012 0:00:00

That image gives an 404-error here too:
http://tools.pingdom.com/fpt/#!/IWPknmbNB/http://i1214.photobucket.com/albums/cc482/mediamalaya/neelofa1.jpg
And:
http://tools.pingdom.com/fpt/#!/rT3YYEcWP/http://i1214.photobucket.com/albums/cc482/mediamalaya/neelofa1.jpg
It seems photobucket has some kind of hotlink/directlink protection.

Comments

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 1-3-2012 15:27:00

That image gives an 404-error here too:
http://tools.pingdom.com/fpt/#!/IWPknmbNB/http://i1214.photobucket.com/albums/cc482/mediamalaya/neelofa1.jpg
And:
http://tools.pingdom.com/fpt/#!/rT3YYEcWP/http://i1214.photobucket.com/albums/cc482/mediamalaya/neelofa1.jpg
It seems photobucket has some kind of hotlink/directlink protection.

Original UserVoice Submission

able to remove black/white whitespace [3083264]

Submitted by sinz on 17-8-2012 0:00:00
1 votes on UserVoice prior to migration

able to trim/remove black bar such as on youtube.
eg: http://i.ytimg.com/vi/9bZkp7q19f0/hqdefault.jpg to http://i.imgur.com/hBDi4.png

Response

by Andries Louw Wolthuizen on 5-1-2013 0:00:00

Wrote an implementation for your idea, would you please test this option for me?
I added the parameter “&trim”, with the option of setting the sensitivity. Default this sensitivity is 10.
The sensitivity defines how black/white/etc the borders must be. For example: your image has a colored border ranging from #000000 (pitch black) to #0F0000.
Example with default sensitivity:
http://images.weserv.nl/?url=i.ytimg.com/vi/9bZkp7q19f0/hqdefault.jpg&trim
Example with sensitivity of 20:
http://images.weserv.nl/?url=i.ytimg.com/vi/9bZkp7q19f0/hqdefault.jpg&trim=20
Example with a lot of other options, and a sensitivity of 20:
http://images.weserv.nl/?url=i.ytimg.com/vi/9bZkp7q19f0/hqdefault.jpg&trim=20&h=200&w=200&t=square
Any comments are welcome!

Comments

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 17-8-2012 21:39:00

Nice idea! Will try to write an implementation for this, thanks for the suggestion!

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 29-9-2012 19:47:00

Wrote an implementation for your idea, would you please test this option for me?
I added the parameter "&trim", with the option of setting the sensitivity. Default this sensitivity is 10.
The sensitivity defines how black/white/etc the borders must be. For example: your image has a colored border ranging from #000000 (pitch black) to #0F0000.
Example with default sensitivity:
http://images.weserv.nl/?url=i.ytimg.com/vi/9bZkp7q19f0/hqdefault.jpg&trim
Example with sensitivity of 20:
http://images.weserv.nl/?url=i.ytimg.com/vi/9bZkp7q19f0/hqdefault.jpg&trim=20
Example with a lot of other options, and a sensitivity of 20:
http://images.weserv.nl/?url=i.ytimg.com/vi/9bZkp7q19f0/hqdefault.jpg&trim=20&h=200&w=200&t=square
Any comments are welcome!

Comment by sinz on 3-10-2012 10:10:00

awesome man!!

Comment by Hammad on 3-12-2012 20:44:00

Just Want to say thanks alot for this wonderful service,it will save alot of cpu usage and memory for me

Comment by scc on 6-10-2014 12:40:00

Super useful, thanks!

Original UserVoice Submission

Output "auto" - return best optimized/supported format [16591912]

Submitted by Binyamin on 10-10-2016 0:00:00
1 votes on UserVoice prior to migration

Like https://images.weserv.nl/?url=rbx.weserv.nl/lichtenstein.jpg might return even better optimized image when returned as PNG, WebP, BPG or else. You can compare before returning the final result.
Still not all browsers supports WebP, BPG. You can check HTTP header "Accept" like value "image/webp" in order to check if even compare/return WebP format.
BPG is still under proposal in browsers (might take a years till actually supported).

Response

by Andries Louw Wolthuizen on 11-10-2016 0:00:00

This cannot be done, because CloudFlare is not browser aware in caching. Even our own implementation of caching in Nginx is based on CloudFlare’s implementation, and disregards different browsers. We use CloudFlare in the front-end, check: https://imagesweserv.uservoice.com/knowledgebase/articles/254818-caching-of-resized-images-server-side-caching
Full WebP-support is planned (currently outputting in WebP is still in development). BPG is not on our roadmap yet.

Comments

Comment by Binyamin on 12-10-2016 22:02:00

You can use CloudFlare "Page Rules" to avoid cache when "&output=auto".

Original UserVoice Submission

Are you saving / caching images forever? [4238722]

Submitted by Nick @ www.merq.org on 27-7-2013 0:00:00
0 votes on UserVoice prior to migration

You are caching the images. But how long? When does the server refresh images?
Example: Image chached, original image deleted. Does the server output the image after some time?
Thanks!

Response

by Andries Louw Wolthuizen on 19-9-2013 0:00:00

The image will be deleted eventually, but there are a lot of different caches. I expect it to be deleted between 14 and 60 days, depending on the amount of requests an image gets.
Images that are getting almost none requests will be deleted sooner.
The server will only initiate a refresh when all caches have expired, and only when the image is still being requested by end users.

Comments

Comment by Donna on 30-10-2013 2:42:00

Hi there
Is there any image program which supports to output the image after some time?
I have delete my tiff files using this program:
http://www.rasteredge.com/how-to/csharp-imaging/tiff-delete/
But now i want to output it again.

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 1-11-2013 19:09:00

This proxy is coded in PHP, we don't have any knowledge about C# or the program you're linking to.

Original UserVoice Submission

Images uploaded from mobile devices turned sideways [4003609]

Submitted by Malte on 28-5-2013 0:00:00
1 votes on UserVoice prior to migration

This image was uploaded from a mobile device. The browser rotates it automatically:
http://static.living.is/gallery/original/1e6a051bbec8ac3471a779936b8f43a7.jpg
Resized by your servers, its turned sideways.
http://images.weserv.nl/?url=static.living.is/gallery/original/1e6a051bbec8ac3471a779936b8f43a7.jpg?w=500
Is there a way to fix that?

Response

by Andries Louw Wolthuizen on 6-6-2013 0:00:00

Browsers like Chrome rotate such images, relying on the EXIF-parameter “Orientation”.
I modified the code of images.weserv.nl, so from now on such images will be rotated automatically to the right position before processing them further.
Keep in mind that, while I emptied some caches, this affects only the images processed from now on. Older images/thumbnails reside up to 30 days in cache, before they get regenerated
For example, these URL’s show the new code in action:
http://images.weserv.nl/?url=static.living.is/gallery/original/1e6a051bbec8ac3471a779936b8f43a7.jpg
http://images.weserv.nl/?url=static.living.is/gallery/original/1e6a051bbec8ac3471a779936b8f43a7.jpg&w=100&h=100&t=square
Let me know if this is what you wanted!

Comments

Comment by Malte on 28-5-2013 22:10:00

Yes, that's exactly what I wanted! Thank you!

Original UserVoice Submission

Chosable transformations [2478876]

Submitted by Andries Louw Wolthuizen on 29-12-2011 0:00:00
0 votes on UserVoice prior to migration

Let users choose how the image should be resized.

Original UserVoice Submission

follow url [3351717]

Submitted by sinz on 14-11-2012 0:00:00
1 votes on UserVoice prior to migration

can it follow this url?
bm.malaysia-chronicle.com/media/k2/items/cache/292622165e02da58dae9b0058e6c4311_Generic.jpg
it will redirect to http://cdnbm.malaysia-chronicle.com/media/k2/items/cache/292622165e02da58dae9b0058e6c4311_Generic.jpg

Response

by Andries Louw Wolthuizen on 5-1-2013 0:00:00

When accessing bm.malaysia-chronicle.com the server receives this response headers:
0 => HTTP/1.1 403 Forbidden 1 => Date: Wed, 14 Nov 2012 10:47:59 GMT 2 => Server: Apache 3 => Content-Length: 386 4 => Connection: close 5 => Content-Type: text/html; charset=iso-8859-1
Which means that the owner of bm.malaysia-chronicle.com blocked the proxy from accessing his site. There is nothing I can do about this.
I however changed the script. It will show some details about the response it receives from servers, to help debugging.
For example: http://images.weserv.nl/?url=bm.malaysia-chronicle.com/media/k2/items/cache/292622165e02da58dae9b0058e6c4311_Generic.jpg

I’m sorry I cannot help you fix this problem, please use cdnbm.malaysia-chronicle.com.

Comments

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 14-11-2012 10:54:00

Will investigate this issue, servers should follow 301 or 302 redirects, but it seems there is some error.
As for now, please use the cdnbm url till I found a solution.

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 14-11-2012 11:51:00

When accessing bm.malaysia-chronicle.com the server receives this response headers:
[0] => HTTP/1.1 403 Forbidden
[1] => Date: Wed, 14 Nov 2012 10:47:59 GMT
[2] => Server: Apache
[3] => Content-Length: 386
[4] => Connection: close
[5] => Content-Type: text/html; charset=iso-8859-1
Which means that the owner of bm.malaysia-chronicle.com blocked the proxy from accessing his site. There is nothing I can do about this.
I however changed the script. It will show some details about the response it receives from servers, to help debugging.
For example: http://images.weserv.nl/?url=bm.malaysia-chronicle.com/media/k2/items/cache/292622165e02da58dae9b0058e6c4311_Generic.jpg

I'm sorry I cannot help you fix this problem, please use cdnbm.malaysia-chronicle.com.

Comment by sinz on 15-11-2012 8:43:00

do you use php curl?
curl_setopt( $ch, CURLOPT_FOLLOWLOCATION, true );

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 15-11-2012 20:08:00

No, because the script doesn't use curl. But yes, we do follow 301 or 302. The problem is that images.weserv.nl is blocked by bm.malaysia-chronicle.com.

Original UserVoice Submission

can you add support in webp from jpg? [15966898]

Submitted by gal on 8-9-2016 0:00:00
1 votes on UserVoice prior to migration

Response

by Andries Louw Wolthuizen on 11-10-2016 0:00:00

This is planned. Related to: #68

Original UserVoice Submission

error 404 [2607996]

Submitted by sinz on 18-2-2012 0:00:00
1 votes on UserVoice prior to migration

screenshot - http://i.imgur.com/LXD7W.png
http://images.weserv.nl/index.php?url=2.bp.blogspot.com/-vMJlc3TgDqE/Tz7i0kzGWkI/AAAAAAAAHic/6D4_b0kPT5o/s72-c/frontpage.jpg&w=60&h=60&t=square';
the image is here ;status code:200 - http://2.bp.blogspot.com/-vMJlc3TgDqE/Tz7i0kzGWkI/AAAAAAAAHic/6D4_b0kPT5o/s72-c/frontpage.jpg

Response

by Andries Louw Wolthuizen on 18-2-2012 0:00:00

If these black images keep recurring, I’m going to review some code..

Comments

Comment by sinz on 18-2-2012 0:57:00

admin, can i have your email please. so i can report bug easily. thanks

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 18-2-2012 1:54:00

Sure, use [email protected]
Your image seems to have triggered an strange condition somehow, don't know if it's blogspot fault or not, I deleted it from the cache, should be working now.

Original UserVoice Submission

turn of the debug [2592037]

Submitted by sinz on 12-2-2012 0:00:00
1 votes on UserVoice prior to migration

http://i.imgur.com/dgJ6H.png

Response

by Andries Louw Wolthuizen on 12-2-2012 0:00:00

Done! Thank you

Original UserVoice Submission

404 image bug [2924845]

Submitted by sinz on 14-6-2012 0:00:00
1 votes on UserVoice prior to migration

the image return 200 status - http://static.palingseru.com/2012/06/a98208_rsz_blow-up-doll-clothes-12-300x217.jpg
http://images.weserv.nl/?url=static.palingseru.com/2012/06/a98208_rsz_blow-up-doll-clothes-12-300x217.jpg&w=60&h=60&t=square&a=t

Response

by Andries Louw Wolthuizen on 14-6-2012 0:00:00

Seems to be fixed already, probably the image wasn’t properly propagated to all caches

Original UserVoice Submission

Return default image if the image's URL not found [2924913]

Submitted by Alif Alfiandy on 14-6-2012 0:00:00
12 votes on UserVoice prior to migration

Let say if the image from hosting was removed but the image's URL is still in the database, then it will not load the image as the 404 error happens. My idea is, to replace the 404 error with default image so that we will never see the broken image on our website.

Response

by Andries Louw Wolthuizen on 3-3-2014 0:00:00

We will reconsider to implement this like Nick suggested. I don’t know how many changes there are needed in different parts of the proxy to make this work flawless.
In the meanwhile, please use the onerror event on an img-tag ( http://www.w3schools.com/jsref/event_img_onerror.asp ).
See:
http://www.askdavetaylor.com/how_to_display_image_not_found_graphic_html_javascript_onerror.html
Or this stackoverflow-thread about how to handle this in jQuery:
http://stackoverflow.com/questions/92720/jquery-javascript-to-replace-broken-images

Comments

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 14-6-2012 12:54:00

Please use the onerror event on an img-tag ( http://www.w3schools.com/jsref/event_img_onerror.asp ), I cannot keep track of all requested images, nor serve default images on an 404-error, this would change default behaviour of the proxy on which third-party's rely.
See:
http://www.askdavetaylor.com/how_to_display_image_not_found_graphic_html_javascript_onerror.html
Or this stackoverflow-thread about how to handle this in jQuery:
http://stackoverflow.com/questions/92720/jquery-javascript-to-replace-broken-images

Comment by Nick @ www.merq.org on 3-3-2014 11:54:00

I am also interested in this feature. Gravatar has a similar service.
A &errorredirect parameter would be great. If there are errors and this param is set your service could send a redirect to this url with the error id (&error=404).
Example:
http://images.weserv.nl/?url=example.org/noimage.jpg&errorredirect=http%3A%2F%2Fimages.weserv.nl%2F%3Furl%3Dwww.google.nl%2Flogos%2Flogo.gif%26h%3D45
Redirect to:
http://images.weserv.nl/?url=www.google.nl/logos/logo.gif&h=45&error=404
&error=404 is only for information if somebody will show dynamic error images via php.

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 3-3-2014 20:01:00

We will reconsider to implement this like Nick suggested. I don't know how many changes there are needed in different parts of the proxy to make this work flawless.

Original UserVoice Submission

Allow us to host on our own server [3519754]

Submitted by Marcus Greenwood on 5-1-2013 0:00:00
1 votes on UserVoice prior to migration

It would be great if we can self-host this. Is it open source?

Response

by Andries Louw Wolthuizen on 19-9-2013 0:00:00

The image proxy is free for use to anyone, and we offer it as-is, it’s just basic image resizing, available to anyone, easy to use. We try to keep everyone as happy as we can.
If you’re however interested in running the source code yourself, and use the service internally, please e-mail me on postmaster at weserv dot nl. The code isn’t open source, as in, open for everyone, but we do let company’s run it internally, which is evaluated on a case-by-case basis. The whole system is written in PHP, uses an file-based caching system, and on top of that utilizes normal HTTP reverse proxy’s to perform well under excessive load.
I hope to have answered your question.

Original UserVoice Submission

to support url with unicode characters [4033438]

Submitted by Simon Lock on 6-6-2013 0:00:00
1 votes on UserVoice prior to migration

Response

by Andries Louw Wolthuizen on 11-10-2013 0:00:00

Added basic support for unicode characters: http://images.weserv.nl/?url=upload.wikimedia.org/wikipedia/commons/thumb/1/1f/Piktogramm_Verbot_%DF.svg/500px-Piktogramm_Verbot_%DF.svg.png
Or copy-paste this to the browser:
http://images.weserv.nl/?url=upload.wikimedia.org/wikipedia/commons/thumb/1/1f/Piktogramm_Verbot_ß.svg/500px-Piktogramm_Verbot_ß.svg.png
IDN-domains are (mostly) supported:
http://images.weserv.nl/?url=realacademiaespañola.es/images/escRAE2.jpg&h=250
IDN-TLD’s cannot be implemented at this moment ( http://en.wikipedia.org/wiki/Internationalized_domain_name#Top-level_domain_implementation ).
I’d like to know if this is what you want, please give me info about URL’s that dont work.

Comments

Comment by Simon Lock on 10-6-2013 15:49:00

Here is a testing photo:
http://images.weserv.nl/?url=www.almega.com.hk/testing/%E6%B8%AC%E8%A9%A6%E5%9C%96%E7%89%87.jpg

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 10-6-2013 17:33:00

Thanks for the URL, I tried a few things, and it seems cURL (external library this proxy uses for image fetching) is failing. The script will now parse the URL correctly, now I only need some way to retrieve it properly.
This needs some time to fix, thanks for the patience!

Original UserVoice Submission

imgur image cache failed [10700433]

Submitted by Anonymous on 14-11-2015 0:00:00
1 votes on UserVoice prior to migration

https://images.weserv.nl/?url=i.imgur.com%2F7Wc71ci.jpg "Error 521"
the origin image "http://i.imgur.com/7Wc71ci.jpg" exists, but cache failed, please help

Response

by Andries Louw Wolthuizen on 14-11-2015 0:00:00

We had some issues, which are solved now.

Original UserVoice Submission

What happened to SPDY Support? [2679854]

Submitted by Ataa on 14-3-2012 0:00:00
1 votes on UserVoice prior to migration

Response

by Andries Louw Wolthuizen on 5-1-2013 0:00:00

Together with CloudFlare SPDY is again enabled for images.weserv.nl!
We’ll continue to fine-tune SPDY-support over the next few weeks.

Comments

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 14-3-2012 21:14:00

CloudFlare, our CDN partner doesn't support SPDY, and we cannot simply handle all traffic by ourself anymore, especially international traffic has been a mayor headache concerning peering and bandwidth agreements. Using a CDN results in lower response times, which benefit our users more than enabling SPDY-support. We do hope to reach an agreement on SPDY support with CloudFlare however, because we still stand behind the improvements SPDY offers in terms of reducing TCP-roundtrips, and with that, improving page load times.

Comment by Ataa on 14-3-2012 21:16:00

Thanks for clarification.

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 19-3-2012 10:34:00

Update: CloudFlare has SPDY on the roadmap, I will update this issue as soon as there is more news.

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 26-6-2012 23:38:00

Update: We will roll out SPDY support anytime now, as CloudFlare is making progress with testing.
See also: http://blog.cloudflare.com/introducing-spdy

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 28-7-2012 1:36:00

Update: Together with CloudFlare SPDY is again enabled for images.weserv.nl!
We’ll continue to fine-tune SPDY-support over the next few weeks.

Original UserVoice Submission

Imgur Problem [2992165]

Submitted by sinz on 11-7-2012 0:00:00
1 votes on UserVoice prior to migration

http://i.imgur.com/GXoWy.jpg working fine but
http://images.weserv.nl/?url=i.imgur.com/GXoWy.jpg&w=60&h=60&t=square&a=t
return "Error 404: Server could not reach the ?url= that you were looking for. The file doesn't exists, or it isn't a valid image. " error

Response

by Andries Louw Wolthuizen on 29-8-2013 0:00:00

I will investigate this issue again. Seems to be temporary problems, maybe there is a way to workaround them.

Comments

Comment by J on 24-6-2013 20:51:00

I'm seeing the same issue. Also it seems random, like for example this works :
http://images.weserv.nl/?url=i.imgur.com%2FDc9YcP2.jpg&w=511&il
but this doesn't:
http://images.weserv.nl/?url=i.imgur.com%2F9fnmaYj.jpg&w=511

Comment by sinz on 19-3-2014 10:40:00

im facing same issue, http://images.weserv.nl/?url=i.imgur.com%2FqU19WcF.jpg&w=166&h=95&t=square

Original UserVoice Submission

Add a parameter to define the compression level [2693320]

Submitted by Anonymous on 18-3-2012 0:00:00
0 votes on UserVoice prior to migration

At the moment the JPEG Compression level seems quite high, would be great to have a way to control it.

Response

by Andries Louw Wolthuizen on 31-3-2012 0:00:00

Added the parameter &q=
You can use any value between 0 and 95. If you don’t specify a quality it defaults to 95 (which is the quality setting all images were using before implementation). This parameter is only effective for JPEG-images.

Comments

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 19-3-2012 10:26:00

Thanks for the suggestion! This needs some changes here and there, but expect it to be implemented within one week.

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 19-3-2012 21:24:00

Added the parameter &q=
You can use any value between 0 and 95. If you don't specify a quality it defaults to 95 (which is the quality setting all images were using before implementation). This parameter is only effective for JPEG-images.
Please test this parameter, if there aren't any problems, I'll update the documentation accordingly and mark this suggestion as completed. Thank you in advance.

Original UserVoice Submission

Aligning [2570350]

Submitted by sinz on 5-2-2012 0:00:00
1 votes on UserVoice prior to migration

Image can be aligning to top, bottom,
somthing like http://www.binarymoon.co.uk/demo/timthumb-cropping/

Response

by Andries Louw Wolthuizen on 17-2-2012 0:00:00

Updated the documentation, which marks this suggestion as completed!

Comments

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 10-2-2012 21:25:00

As I said I would do on February 5, I just implemented this option:
Left/right:
https://images.weserv.nl/?url=www.binarymoon.co.uk/demo/timthumb-cropping/lighthouse.jpg&t=square&a=l&w=60&h=130
https://images.weserv.nl/?url=www.binarymoon.co.uk/demo/timthumb-cropping/lighthouse.jpg&t=square&a=r&w=60&h=130
Top/bottom:
https://images.weserv.nl/?url=www.binarymoon.co.uk/demo/timthumb-cropping/lighthouse.jpg&w=130&h=90&t=square&a=t
https://images.weserv.nl/?url=www.binarymoon.co.uk/demo/timthumb-cropping/lighthouse.jpg&w=130&h=90&t=square&a=b
I will update the documentation accordingly soon

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 17-2-2012 23:15:00

Updated the documentation, which marks this suggestion as completed!

Original UserVoice Submission

How to setup proxy server on APACHE server ? any tutorial ? [13031043]

Submitted by Darpa on 18-3-2016 0:00:00
1 votes on UserVoice prior to migration

how to setup source (github) of proxy on apache based linux server, shared hosting ?

Response

by Andries Louw Wolthuizen on 18-3-2016 0:00:00

Hi Darpa,
There is no support on self hosting the code; the service is provided as-is. If your usercase is so specific, you would be experienced enough to do so. Take a look on our GitHub page. All the code is in index.php. Tutorials on setting up webservers can be found online.
Bugs can be reported, and our team will look into it, however, we cannot support self hosted installations. There is no security or access control involved, if you want this, please code it yourself.
If you don’t trust yourself, please use the online service we provide on images.weserv.nl as-is, it is free to use.
I’m sorry that we cannot provide additional support on this matter.
Greetings,
Andries Louw Wolthuizen

Original UserVoice Submission

Add support to fetch images over HTTPS [2693328]

Submitted by Anonymous on 18-3-2012 0:00:00
0 votes on UserVoice prior to migration

Response

by Andries Louw Wolthuizen on 5-1-2013 0:00:00

Sorry for the late update on this question, but you can now use the prefix ssl:
Example:
http://images.weserv.nl/?url=ssl:www.google.com/logos/logo.gif
Will fetch https://www.google.com/logos/logo.gif
If you’re experiencing any issues, please report them!

Comments

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 19-3-2012 10:32:00

Good idea! I'll need to investigate how much changes this requires in our code, this is because of the different caching- and connection-layers when retrieving images from their origin.
It is, however, something that has been on our wish-list as well, thanks for bringing it under attention again!

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 26-6-2012 23:32:00

Sorry for the late update on this question, but you can now use the prefix ssl:
Example:
http://images.weserv.nl/?url=ssl:www.google.com/logos/logo.gif
Will fetch https://www.google.com/logos/logo.gif
If you're experiencing any issues, please report them!

Comment by Luuk Lamers on 1-2-2016 20:15:00

Hi there, I've run into a problem where using SSL'ed images.weserv loading SSL'ed images from my domain returns "#35: SSL connect error". Any ideas where this is coming from? I'm using CloudFlare to tunnel my site through SSL with "https everywhere" setting on.

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 1-2-2016 21:21:00

Hi Luuk,
We use cURL for fetching of the original images, maybe the certificate is bad, maybe the handshake didn't succeed, or something else happened. Error's from cURL are directly passed to aid in debugging.
Could you please test the origin host (the host that is responsible for the original image) with something like https://www.ssllabs.com/ssltest/ ? It will pinpoint errors pretty fast.
Let me know!

Comment by Luuk Lamers on 4-2-2016 21:04:00

Checked it out. ssktest doesn't seem to think there's a problem.
https://www.ssllabs.com/ssltest/analyze.html?d=dim.nl

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 4-2-2016 22:24:00

Hi Luuk,
Thanks for giving your domain, I discovered there's a bug with certificate negotiation in the version of cURL that comes with CentOS 6.x, which our servers use. I updated cURL to the newest available version, and it seems to be solved now.
However, we have some aggresive caching in place, so you may need to try new url's (by adding &test=1 to them, for example).

Comment by Luuk Lamers on 5-2-2016 20:39:00

Glad to help ;)
I'm happy it works now.
Thanks (bedankt!)

Comment by apichaidot on 2-1-2017 2:37:00

I try to use prefix ssl:
https://images.weserv.nl/?url=ssl:f.ptcdn.info/133/031/000/1431060027-2015050823-o.png&h=300
and I got an error below.
Error 404: Server could parse the ?url= that you were looking for, error it got: Maximum (10) redirects followed
Original Link=https://f.ptcdn.info/133/031/000/1431060027-2015050823-o.png
Please help me

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 2-1-2017 21:47:00

Hi apichaidot,
The link you gave is working here, could it be a temporary issue?
Let me know!

Comment by apichaidot on 3-1-2017 8:47:00

Hi Andries,
Now it works. thank for kindly support.

Original UserVoice Submission

Left is right and right is left [14887038]

Submitted by 1v on 21-6-2016 0:00:00
3 votes on UserVoice prior to migration

left and right align image relatively to canvas:
https://images.weserv.nl/?url=www.google.com/images/title_homepage4.gif&q=100&w=50&h=50&a=left&t=square
but top and bottom align canvas relatively to image:
https://images.weserv.nl/?url=encrypted.google.com/images/nav_logo242.png&q=100&w=100&h=100&a=top&t=square
one of these is wrong.

Response

by Andries Louw Wolthuizen on 23-6-2016 0:00:00

You are right! Solved it, see 0d59a51
Thanks for noticing!

Original UserVoice Submission

Use Coudflare DNS and proxy [16591702]

Submitted by Binyamin on 10-10-2016 0:00:00
1 votes on UserVoice prior to migration

Coudflare would benefit CDN delivery, better security and caching (you can set "Cache All"), over HTTP/2. Image optimization is applied when using Pro plan.

Response

by Andries Louw Wolthuizen on 11-10-2016 0:00:00

We are already using CloudFlare for many many years, this is stated clearly on the frontpage, and in the knowledgebase: https://imagesweserv.uservoice.com/knowledgebase/articles/254818-caching-of-resized-images-server-side-caching
Caching is custom-set with page-rules, but please, read the knowledgebase before you ask more questions. Image Optimization from CloudFlare relies heavily on javascript-injection, and for that reason, has been turned off since the beginning.

Original UserVoice Submission

Add Content-Length header to allow for indeterminate progress. [13345773]

Submitted by Andrew Yates on 7-4-2016 0:00:00
3 votes on UserVoice prior to migration

Would be awesome to add the Content-Length header to allow for progress to be calculated when downloading images. Guess this may only be possible when serving the image from cache.

Response

by Andries Louw Wolthuizen on 10-4-2016 0:00:00

For images we’re now running a test case with returning proper Content-Length headers.
Error-messages, and base64-results will still be send by using Transfer-Encoding:chunked as per https://en.wikipedia.org/wiki/Chunked_transfer_encoding
We’ll monitor this for a while, before deciding if this header will stay or not.

Comments

Comment by Andrew Yates on 11-4-2016 22:49:00

That's awesome, already seeing the indeterminate progress indicator working well within our app. Thanks!

Original UserVoice Submission

API params without query usage [16592635]

Submitted by Binyamin on 10-10-2016 0:00:00
1 votes on UserVoice prior to migration

Problem:

1. The "url" value might contain query params used in images.weserv.nl API what causes https://images.weserv.nl/?w=30&h=30&url=domain.com/image&w=300&h=300 return image size 300x300 while expected in size 30x30. And what if http://domain.com/image&w=300&h=300 size is 500x900 and user tries https://images.weserv.nl/?url=domain.com/image&w=300&h=300 ... I know encoded url may avoid that issue, still encoded URL will cost excrta chars...
2. Queries costs an extra characters in URL
   I recommend you to consider to use Rewrite Rules and API examples from http://cloudinary.com/documentation/fetch_remote_images

Response

by Andries Louw Wolthuizen on 11-10-2016 0:00:00

You can use url-encoded URL’s, which is stated in the manual on the frontpage. It’s a really bad idea to use the Cloudinary system, because lot’s of UBB systems will misrecognize the second http:// part.
We will not change to the Cloudinary system, it uses as many chars as our system, even more in most cases. Consider /w_300,h_300/http:// versus ?w=300&h=300&url=. So Cloudinary is actually the one that uses the most characters.

Original UserVoice Submission

png transparency is lost [3835046]

Submitted by anonymous on 9-4-2013 0:00:00
1 votes on UserVoice prior to migration

png transparency is lost

Response

by Andries Louw Wolthuizen on 6-6-2013 0:00:00

I’m sorry, can you give me an example which fails? It seems to work to me:
http://images.weserv.nl/?url=upload.wikimedia.org/wikipedia/commons/thumb/2/2a/Wikipe-tan_in_navy_uniform2_transparent.png/600px-Wikipe-tan_in_navy_uniform2_transparent.png&h=200
Semi-transparency also seems to work:
http://images.weserv.nl/?url=www.w3.org/Graphics/PNG/alphatest.png&h=150
Thank you!

Original UserVoice Submission

Manage cyrilic and arabic caracters [15427689]

Submitted by Anonymous on 27-7-2016 0:00:00
1 votes on UserVoice prior to migration

Hello,
The service works fine except when I try to use cyrilic and arabic caracters
ex: https://images.weserv.nl/?url=%2F%2Ftalkalang-avatars.s3-eu-west-1.amazonaws.com%2FzzcmNEhWHMgCSFKBF%2F%D0%9A%D0%B2%D0%B0%D0%B4%D1%80%D0%B0%D1%82.png

Response

by Andries Louw Wolthuizen on 28-7-2016 0:00:00

Will do, may take some time to fix all the issues, thanks for reporting this issue!

Original UserVoice Submission

Need Implement 304 Not modify Http Response code [3356424]

Submitted by Thanh Tung on 15-11-2012 0:00:00
1 votes on UserVoice prior to migration

Hi your service is so good and very useful for me. But you need implement "304 Not Modified" to reduce your server bandwidth and response time when image reload.
Thanks so much.

Response

by Andries Louw Wolthuizen on 5-1-2013 0:00:00

Images.weserv.nl disables 2 (default) settings regarding to cache-control. These are the ETag header, and the Last-Modified header.
We do set the Cache-Control header. Allow me to explain this decision, using Apache-config. (Images.weserv.nl uses NGINX on all servers, but Apache is more common for most people, and we did use Apache about a year ago)
Consider the following Apache settings, these are identical to the NGINX-settings we use:
Header unset ETag
FileETag None
Header set Cache-Control “max-age=2678400”
The first two rules disable ETag’s completely, so the browser is somewhat forced to listen to the Cache-Control header. The last rule tells the browser to cache the file 2678400 seconds, or 1 month.
Optional, we use multiple servers to serve static content, and we are not sure about the last-modified times those servers report, because each has his own version of the cache, so we also use:
Header unset Last-Modified
It tells Apache to not serve any Last-Modified headers, so browsers can only listen to the Cache-Control max-age header.
This settings are used by us on lots of hightraffic websites, and disabling of ETag’s and Last-Modified headers sure helped to drive traffic down to one fifth of what it used to be. Especially Internet Explorer is very sensitive to those settings.
Disabling Last-Modified will stop browsers from asking 304 Content Not Modified requests. In my experience this is positive, because the webserver has less requests to process, and browsers rely more on the Cache-Control settings you serve. But it may or may not suit you. Some browsers will try to validate assets every few minutes if you serve them a “Last-Modified” header, and that’s why I would advice to disable the use of it completely.
If you want more information about the headers we serve, consider using http://redbot.org/ this will explain every header we serve, and why this is used. We also serve Cache-Control: public, this allows browsers to cache things even when accessing images.weserv.nl over https://
Please let me know if you need more info, I’m also open for comments about the caching policies we use. We do run complete tests on server load, bandwidth, and CPU-cycles, for each header we place. Enabling 304 will generate 5 times more requests from browsers in our case, this could be different for your site, but I expect it to be the same.

Comments

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 15-11-2012 20:14:00

Disabling 304 responses works better and generates 80% less traffic and server load. I will explain this later today in detail.

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 15-11-2012 20:25:00

Images.weserv.nl disables 2 (default) settings regarding to cache-control. These are the ETag header, and the Last-Modified header.
We do set the Cache-Control header. Allow me to explain this decision, using Apache-config. (Images.weserv.nl uses NGINX on all servers, but Apache is more common for most people, and we did use Apache about a year ago)
Consider the following Apache settings, these are identical to the NGINX-settings we use:
Header unset ETag
FileETag None
Header set Cache-Control "max-age=2678400"
The first two rules disable ETag's completely, so the browser is somewhat forced to listen to the Cache-Control header. The last rule tells the browser to cache the file 2678400 seconds, or 1 month.
Optional, we use multiple servers to serve static content, and we are not sure about the last-modified times those servers report, because each has his own version of the cache, so we also use:
Header unset Last-Modified
It tells Apache to not serve any Last-Modified headers, so browsers can only listen to the Cache-Control max-age header.
This settings are used by us on lots of hightraffic websites, and disabling of ETag's and Last-Modified headers sure helped to drive traffic down to one fifth of what it used to be. Especially Internet Explorer is very sensitive to those settings.
Disabling Last-Modified will stop browsers from asking 304 Content Not Modified requests. In my experience this is positive, because the webserver has less requests to process, and browsers rely more on the Cache-Control settings you serve. But it may or may not suit you. Some browsers will try to validate assets every few minutes if you serve them a "Last-Modified" header, and that's why I would advice to disable the use of it completely.
If you want more information about the headers we serve, consider using http://redbot.org/ this will explain every header we serve, and why this is used. We also serve Cache-Control: public, this allows browsers to cache things even when accessing images.weserv.nl over https://
Please let me know if you need more info, I'm also open for comments about the caching policies we use. We do run complete tests on server load, bandwidth, and CPU-cycles, for each header we place. Enabling 304 will generate 5 times more requests from browsers in our case, this could be different for your site, but I expect it to be the same.

Original UserVoice Submission

Allow 256 colors for small screens [10265160]

Submitted by joey liechty on 19-10-2015 0:00:00
1 votes on UserVoice prior to migration

I am trying to display images on a pebble smart watch and I think there's a limitation on how many colors I can display on it.

Response

by Andries Louw Wolthuizen on 19-10-2015 0:00:00

Hi Joey,
Unfortunate the pebble watch only support 64 colors, or only black/white, depending on the image you have.
Pebble has his own utility for converting those images, please look at:
http://developer.getpebble.com/guides/pebble-apps/resources/image-resources/
I cannot incorporate this into the sourcecode of images.weserv.nl, because I cannot find the right libraries.

Original UserVoice Submission

+ bug [2586863]

Submitted by sinz on 10-2-2012 0:00:00
1 votes on UserVoice prior to migration

replace + with 2%b but same result
http://4.bp.blogspot.com/-y2_gvZppkms/TxHHbS8Z6jI/AAAAAAAABIc/DbFuRlaA8Ks/s72-c/Honda+NSX+concept+copy.jpg
http://images.weserv.nl/?url=4.bp.blogspot.com/-y2_gvZppkms/TxHHbS8Z6jI/AAAAAAAABIc/DbFuRlaA8Ks/s72-c/Honda%2BNSX%2Bconcept+copy.jpg

Response

by Andries Louw Wolthuizen on 12-2-2012 0:00:00

I cannot solve the problem for this image, because it doesn’t exist, I cannot reach: http://4.bp.blogspot.com/-y2_gvZppkms/TxHHbS8Z6jI/AAAAAAAABIc/DbFuRlaA8Ks/s72-c/Honda+NSX+concept+copy.jpg
My browser reports an 404 header, and shows an exclamation mark.
I fixed some other problems though, that are somewhat related to + s and spaces in url’s. Please check your URL’s through http://redbot.org/ to confirm the resource isn’t 404-ed.
An example of a working image:
http://images.weserv.nl/index2.php?url=2.bp.blogspot.com/-bmXaEeWEyB0/TZ6Vf6YpzEI/AAAAAAAABYo/_EOjwot5beg/s1600/color%20block4.jpg
http://images.weserv.nl/index2.php?url=2.bp.blogspot.com/-bmXaEeWEyB0/TZ6Vf6YpzEI/AAAAAAAABYo/_EOjwot5beg/s1600/color+block4.jpg
http://images.weserv.nl/index2.php?url=2.bp.blogspot.com/-bmXaEeWEyB0/TZ6Vf6YpzEI/AAAAAAAABYo/_EOjwot5beg/s1600/color%2Bblock4.jpg
You’ll see that *.bp.blogspot.com accepts an wide range of url’s. I hosted ‘color block4.jpg’ myself, resulting in:
http://images.weserv.nl/?url=images.weserv.nl/color%20block4.jpg
http://images.weserv.nl/?url=images.weserv.nl/color+block4.jpg
Note that the + is transformed to a space, and the following url will not work:
http://images.weserv.nl/?url=images.weserv.nl/color%2Bblock4.jpg
because I didn’t storage ‘color+block4.jpg’ but ‘color block4.jpg’.
Long story short: The proxy shouldn’t have any problems related to + and/or spaces anymore, but you should check the URL you’re using first.

Comments

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 10-2-2012 19:08:00

There are some problems with: +, spaces, %2B and %20. I’m going to look into it, and try to fix this once and for all. Thank you for reporting the URL’s, I couldn’t locate the problem, but I was aware of it somewhere. Expect an fix soon.

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 10-2-2012 19:20:00

I cannot solve the problem for this image, because it doesn't exist, I cannot reach: http://4.bp.blogspot.com/-y2_gvZppkms/TxHHbS8Z6jI/AAAAAAAABIc/DbFuRlaA8Ks/s72-c/Honda+NSX+concept+copy.jpg
My browser reports an 404 header, and shows an exclamation mark.
I fixed some other problems though, that are somewhat related to + s and spaces in url's. Please check your URL's through http://redbot.org/ to confirm the resource isn't 404-ed.
An example of a working image:
http://images.weserv.nl/index2.php?url=2.bp.blogspot.com/-bmXaEeWEyB0/TZ6Vf6YpzEI/AAAAAAAABYo/_EOjwot5beg/s1600/color%20block4.jpg
http://images.weserv.nl/index2.php?url=2.bp.blogspot.com/-bmXaEeWEyB0/TZ6Vf6YpzEI/AAAAAAAABYo/_EOjwot5beg/s1600/color+block4.jpg
http://images.weserv.nl/index2.php?url=2.bp.blogspot.com/-bmXaEeWEyB0/TZ6Vf6YpzEI/AAAAAAAABYo/_EOjwot5beg/s1600/color%2Bblock4.jpg
You'll see that *.bp.blogspot.com accepts an wide range of url's. I hosted 'color block4.jpg' myself, resulting in:
http://images.weserv.nl/?url=images.weserv.nl/color%20block4.jpg
http://images.weserv.nl/?url=images.weserv.nl/color+block4.jpg
Note that the + is transformed to a space, and the following url will not work:
http://images.weserv.nl/?url=images.weserv.nl/color%2Bblock4.jpg
because I didn't storage 'color+block4.jpg' but 'color block4.jpg'.
Long story short: The proxy shouldn't have any problems related to + and/or spaces anymore, but you should check the URL you're using first.

Comment by sinz on 12-2-2012 5:03:00

yeah, its 404.
i thought thats an image http://i.imgur.com/5cDdL.png

Comment by Anonymous on 27-7-2016 23:39:00

impossible to put a URL with cyrilic or arabic caracters
https://images.weserv.nl/?url=%2F%2Ftalkalang-avatars.s3-eu-west-1.amazonaws.com%2FzzcmNEhWHMgCSFKBF%2F%D0%9A%D0%B2%D0%B0%D0%B4%D1%80%D0%B0%D1%82.png

Original UserVoice Submission

Add circle effect to photos [3910149]

Submitted by korayem on 30-4-2013 0:00:00
4 votes on UserVoice prior to migration

Response

by Andries Louw Wolthuizen on 10-5-2013 0:00:00

I modified the effect to your requirements, is this like you want it?
Without:
https://images.weserv.nl/?url=www.bestwalls.net/wp-content/uploads/2013/03/nature-wallpapers-high-resolution.jpg&h=400
With:
https://images.weserv.nl/?url=www.bestwalls.net/wp-content/uploads/2013/03/nature-wallpapers-high-resolution.jpg&h=400&circle
I’d like to hear from you!

Comments

Comment by korayem on 1-5-2013 13:05:00

Hey Andries,
I was referring to croping the image into a circle.
Example:
http://a2.res.cloudinary.com/demo/image/upload/c_fill,g_face,h_114,w_114/face_left.jpg
http://a2.res.cloudinary.com/demo/image/upload/c_thumb,g_face,h_114,r_max,w_114/face_left.jpg

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 3-5-2013 21:56:00

Oh, and if you want it to be a circle (no ellipse), add &t=square and height+width:
https://images.weserv.nl/?url=www.google.com/logos/logo.gif&h=100&w=100&t=square&circle

Comment by korayem on 10-5-2013 4:25:00

That will do the trick! Perfect ;) thanks a ton

Comment by M_awadi on 18-11-2013 18:59:00

hi, nice work dude for Circular image
i just wondering if the circle boarder be like more sharp edges
like this image's boarder: http://a2.res.cloudinary.com/demo/image/upload/c_thumb,g_face,h_114,r_max,w_114/face_left.jpg
the current service produce the circle image's boarder less smooth
i hope it easy to fixe and thank you for this amazing service :)

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 18-11-2013 20:49:00

They use some form of supersampling. I will experiment with some anti-aliasing, but can't promise anything. Supersampling as anti-aliastechnique is computational intensive, and can introduce more errors in the image, than it's trying to fix. However, I do hate those jagged edges in the current implementation.

Comment by Mohamed Naguib on 17-9-2014 13:50:00

Why do I have to set height while adding circle like this
https://images.weserv.nl/?url=www.jpl.nasa.gov/spaceimages/images/mediumsize/PIA17011_ip.jpg&h=400&circle
but when I don't add height, it doesn't circle the photo like this
https://images.weserv.nl/?url=www.jpl.nasa.gov/spaceimages/images/mediumsize/PIA17011_ip.jpg&circle
why don't you just circle the original size of the photo?

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 18-9-2014 0:30:00

Seems to be some strange bug, I'll look into it. Could take some time to fix though, I'm guessing it has something to do with the (new) way we handle images that don't need any transformation or resizing.

Original UserVoice Submission

Browser cache doesn't work, expected to return HTTP 301 [16591651]

Submitted by Binyamin on 10-10-2016 0:00:00
1 votes on UserVoice prior to migration

https://images.weserv.nl/?url=rbx.weserv.nl/lichtenstein.jpg is never cached by browser, it always returns HTTP 200, while when cached expected to return HTTP 301. You can test/check it in https://redbot.org/?uri=https://images.weserv.nl/?url=rbx.weserv.nl/lichtenstein.jpg
Related issue in /archive/suggestion-5701336-specify-a-cache-validator

Response

by Andries Louw Wolthuizen on 11-10-2016 0:00:00

Please check your response codes: 301 is Permanent Redirect, you are probably referring to 304 Not Modified.
Please carefully read: https://github.com/andrieslouw/imagesweserv/wiki/Browser-cache-control-headers-(client-side-caching)
Because the idea you’re proposing is really a bad idea, and will increase traffic. Test your browser, you’ll see that it will cache images from images.weserv.nl just fine! The headers you’re referring too are actually a flawed concept to start with.

Comments

Comment by Binyamin on 12-10-2016 21:07:00

Sorry, I meant 304 and not 301.
https://images.weserv.nl/?url=rbx.weserv.nl/lichtenstein.jpg never returns 304.

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 12-10-2016 23:07:00

I know it never returns 304, that's part of the design, have you read the knowledgebase article I linked? Please do so. Carefully. Because there are good reasons to never use last-modified, to never use 304 and never use Etags. The images are cached without those headers by any modern (post IE6) browser. We use Cache-Control, which will and is working perfect. Please read the knowledgebase article.

Comment by Binyamin on 12-10-2016 23:21:00

@Andries, I read your link few times - unfortunately its isn't how https://images.weserv.nl/?url=rbx.weserv.nl/lichtenstein.jpg currently works (perhaps is a bug).
Double checked, it always returns "Cache-Control:max-age=0", while your documentation mentions Cache-Control "max-age=2678400". It means the browser cache is always avoided.
Interesting that has "Date:Wed, 12 Oct 2016 21:17:17 GMT" and "Expires:Sat, 12 Nov 2016 21:17:17 GMT" and it still doesn't affect the browser cache. Check DEV Tools, the Network expected to show "from disk/memory cache".

Comment by Andries Louw Wolthuizen (Webmaster, Images.weserv.nl - Image cache & resize proxy) on 13-10-2016 7:23:00

That's strange, and would mean that the headers you see are different from these ones: https://redbot.org/?uri=https%3A%2F%2Fimages.weserv.nl%2F%3Furl%3Drbx.weserv.nl%2Flichtenstein.jpg
Just curious; what is your test setup? Which browser and debug-tools are you using?

Comment by Binyamin on 13-10-2016 7:53:00

Sorry, I just noticed "Cache-Control:public, max-age=2678400" in "Response Headers", while in "Request Headers" is still stuck with "Cache-Control:max-age=0", and browsers (latest Chrome, etc.) doesn't ever tries to cache it, but instead makes a server call on every request/refresh.
Are you sure "Last-Modified" must be dropped and with it the new request will allays call the origin server instead of immediate respond from cache (I think browser is expected to compare cached file headers in order to decide if return from cache or make a call to server)?

Original UserVoice Submission

Parameter "url" support also with http?:// [16592074]

Submitted by Binyamin on 10-10-2016 0:00:00
1 votes on UserVoice prior to migration

I propose to allow parameter "url" support also http:// and https://, there are many reasons for it.

1. more consistent API with similar services
2. http and https may respond different results, for example https://a.b/kitties.jpg may return cats image and http://a.b/kitties.jpg error/fallback image or error 404, or else
3. when defined https://... would reduce the server-side loop - wouldn't try check http:// before trying https:// (for example domain might support only https)
   I am fine with to continue to support "url" value without protocol (maybe as a backwards compatibility).

Response

by Andries Louw Wolthuizen on 11-10-2016 0:00:00

As stated on the frontpage, SSL and HTTP is already supported since january 2013: #33
The API is inconsistent to prevent UBB-parsers to fail on the double http://-part. For that reason we use ssl:.
More detailed answer on your questions:

1. See answer above.
2. Yes, sadly, in many cases we tested, HTTPS is wildly different from HTTP. Looking for both increases the parsing time needed to fetch the requested image. Also, for us it doesn’t make sense to always fetch over HTTPS, it’ll only increase lag, and won’t add any security (we could be considered to be a middle-man, and we would only protect against additional middle-mans between our datacenter, and that of the origin. If there is such an attack, SSL wouldn’t help us.).
3. There is no server-side loop, see answer to 1. We only check http:// for ?url=, and only check https:// for ?url=ssl:…-requests.
   And indeed, our system is already backwards-compatible for more than 8 years, so changing such a thing would be a real hassle.
   To summarize: The only new thing in your suggestion is to replace ?url= for ?url=http:// and ?url=ssl: for ?url=https://. This is something we consider as being bad-practice, therefore it is declined.

Original UserVoice Submission

SSL-support on client-side [2478869]

Submitted by Andries Louw Wolthuizen on 29-12-2011 0:00:00
0 votes on UserVoice prior to migration

Make the service reachable over https://

Original UserVoice Submission

CNAME to allow for nicer URLs [3519776]

Submitted by Marcus Greenwood on 5-1-2013 0:00:00
4 votes on UserVoice prior to migration

It would be cool if we could do the following.

1. CNAME our own subdomain e.g. images.mydomain.com -> images.weserv.nl
2. Then reference images like so: http://images.mydomain.com/path/to/myimage.png?width=64
   This would effectively be the same as http://images.weserv.nl/?url=mydomain.com/path/to/myimage.png&width=64
   Of course the caveat being that we would have to setup our own cloudflare/cloudfront/etc on our subdomain to handle the caching.

Response

by Andries Louw Wolthuizen on 16-6-2013 0:00:00

We offer this proxy only on the images.weserv.nl domain, and we offer it as-is. However, if you want to use it under your own (sub)domain, please see the response on your other question:
#45
The goal of this proxy is reaching out to starting websites that don’t have the skills nor resources to script and host something themselves.
We, as a company, make websites, web applications and mobile applications, so the image proxy is used by us and our customers a lot. It’s saving us traffic (through compression), and offloading our main servers, because customers don’t have to use poor self-written scripts for image resizing, instead, they can direct it to images.weserv.nl, which is dedicated to the task.
But, we don’t want to serve the whole internet, aside from the amount of traffic (we already handle a couple of million requests each day, which is great), our opinion is that when sites grow, they probably want to host their own solution. This solution will probably integrate better with their site(s), and will offer many advantages we just can’t.
By making this service freely available (as it is currently, and will be), we gain some experience with different user cases, and our customers appreciate it.
We like to hear your thoughts on this, if you have the resources to build something like you described, we happily point our users towards you if they want something alike. But we don’t expect to offer such features ourself.

Original UserVoice Submission