weserv / images Goto Github PK
View Code? Open in Web Editor NEWSource code of wsrv.nl (formerly images.weserv.nl), to be used on your own server(s).
Home Page: https://wsrv.nl/
License: BSD 3-Clause "New" or "Revised" License
Source code of wsrv.nl (formerly images.weserv.nl), to be used on your own server(s).
Home Page: https://wsrv.nl/
License: BSD 3-Clause "New" or "Revised" License
Submitted by Ataa on 14-3-2012 0:00:00
1 votes on UserVoice prior to migration
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.
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.
Thanks for clarification.
Update: CloudFlare has SPDY on the roadmap, I will update this issue as soon as there is more news.
Update: We will roll out SPDY support anytime now, as CloudFlare is making progress with testing.
See also: http://blog.cloudflare.com/introducing-spdy
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.
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
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.
Sorry, I meant 304 and not 301.
https://images.weserv.nl/?url=rbx.weserv.nl/lichtenstein.jpg never returns 304.
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.
@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".
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?
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)?
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
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!
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.
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.
Submitted by Michal on 26-5-2013 0:00:00
1 votes on UserVoice prior to migration
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.
Wow. Yes, that's perfect, thanks.
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
by Andries Louw Wolthuizen on 14-11-2015 0:00:00
We had some issues, which are solved now.
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
by Andries Louw Wolthuizen on 19-3-2012 0:00:00
I don’t see any problem here, can you describe the issue?
Submitted by Andries Louw Wolthuizen on 29-12-2011 0:00:00
0 votes on UserVoice prior to migration
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.
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.
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?
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.
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
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.
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.
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.
yeah, its 404.
i thought thats an image http://i.imgur.com/5cDdL.png
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
Submitted by Eugene Huseynov on 23-8-2016 0:00:00
24 votes on UserVoice prior to migration
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
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.
Is any api/way to expire/delete/rebuild/invalidate existing image cache?
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!
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
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
Submitted by Binyamin on 10-10-2016 0:00:00
1 votes on UserVoice prior to migration
Problem:
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.
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.
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.
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
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.
Great... Thanks for the explanation.
I guess even a adding an optional query string like force-no-redirect=true would be helpful
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://
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.
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.
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.
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.
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.
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?
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.
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.
thanks
Submitted by Anonymous on 18-3-2012 0:00:00
0 votes on UserVoice prior to migration
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!
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!
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!
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.
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!
Checked it out. ssktest doesn't seem to think there's a problem.
https://www.ssllabs.com/ssltest/analyze.html?d=dim.nl
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).
Glad to help ;)
I'm happy it works now.
Thanks (bedankt!)
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
Hi apichaidot,
The link you gave is working here, could it be a temporary issue?
Let me know!
Hi Andries,
Now it works. thank for kindly support.
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
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
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
Submitted by anonymous on 9-4-2013 0:00:00
1 votes on UserVoice prior to migration
png transparency is lost
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!
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.
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.
Disabling 304 responses works better and generates 80% less traffic and server load. I will explain this later today in detail.
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.
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.
by Andries Louw Wolthuizen on 23-6-2016 0:00:00
You are right! Solved it, see 0d59a51
Thanks for noticing!
Submitted by gal on 8-9-2016 0:00:00
1 votes on UserVoice prior to migration
by Andries Louw Wolthuizen on 11-10-2016 0:00:00
This is planned. Related to: #68
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 ?
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
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
by Andries Louw Wolthuizen on 18-2-2012 0:00:00
If these black images keep recurring, I’m going to review some code..
admin, can i have your email please. so i can report bug easily. thanks
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.
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.
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.
That's awesome, already seeing the indeterminate progress indicator working well within our app. Thanks!
Submitted by sinz on 12-2-2012 0:00:00
1 votes on UserVoice prior to migration
by Andries Louw Wolthuizen on 12-2-2012 0:00:00
Done! Thank you
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
by Andries Louw Wolthuizen on 3-2-2013 0:00:00
Error resolved, cause unknown, seems like a bit fell over.
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?
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!
Yes, that's exactly what I wanted! Thank you!
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.
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.
Thanks for the suggestion! This needs some changes here and there, but expect it to be implemented within one week.
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.
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!
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.
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.
This proxy is coded in PHP, we don't have any knowledge about C# or the program you're linking to.
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
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.
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.
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
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.
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
im facing same issue, http://images.weserv.nl/?url=i.imgur.com%2FqU19WcF.jpg&w=166&h=95&t=square
Submitted by Uri Goldshtein on 25-11-2012 0:00:00
1 votes on UserVoice prior to migration
That will be a huge help!
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!
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!
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/
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.
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
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.
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.
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:
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.
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).
Submitted by korayem on 30-4-2013 0:00:00
4 votes on UserVoice prior to migration
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!
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
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
That will do the trick! Perfect ;) thanks a ton
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 :)
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.
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?
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.
Submitted by Simon Lock on 6-6-2013 0:00:00
1 votes on UserVoice prior to migration
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.
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
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!
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
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!
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:'.
Much thanks! That was pronto.
Best wishes.
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/
by Andries Louw Wolthuizen on 17-2-2012 0:00:00
Updated the documentation, which marks this suggestion as completed!
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
Updated the documentation, which marks this suggestion as completed!
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
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?
works like charm.
thanks!
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
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!
Nice idea! Will try to write an implementation for this, thanks for the suggestion!
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!
awesome man!!
Just Want to say thanks alot for this wonderful service,it will save alot of cpu usage and memory for me
Super useful, thanks!
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.
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
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).
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.
You can use CloudFlare "Page Rules" to avoid cache when "&output=auto".
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.
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
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
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.
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.
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.
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.
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
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
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
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.
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.
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.
do you use php curl?
curl_setopt( $ch, CURLOPT_FOLLOWLOCATION, true );
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.