I have an imgproxy server, as shown below. It's able to transform an image (resize, crop) using URL parameters.
Now I would like to add a caching proxy. So an image only would be processed (resized, cropped) if that doesn't exist in the cache.
I've read that AWS Cloudfront or Cloudflare or maybe Google Cloud CDN could be the caching proxy, what would be great. But unfortunately I didn't find any example of how to do that. I appreciate if anyone can help me.
On Cloudflare, you can leverage the following services for your use case:
Cloudflare Images: for CDN, storage and resizing services
Cloudflare Image Resizing, combined with the Cloudflare CDN via reverse proxy to allow on the fly resizing and optimization of the images (differences with Images listed here)
You can also store and resize images on your site, using the Cloudflare CDN (DNS base reverse proxy) and put it in front of your image resizing and storage stack. This is explained here in detail.
You can find here the steps to create a Cloudflare account and add your domain to it.
Hi Paolo just I also i had same doubt about how to cache, but in my case i want to use a self server,
I created a project they caches the images based on params and url requested these is generated an hash MD5, when the image with same params is requested the proxy search the md5 if is cached otherwise they regenerate a new one image resized
You can consider that for use to S3 / cloudflare any else
You can take a look of the project:
https://github.com/sefirosweb/Imgproxy-With-Cache
Related
I'm having difficulties understanding if my idea of an image gallery will work as I can't seem to get it working.
What I have:
An Google App Engine running with a simple website that serves products where each product can have images
A Google Storage bucket with 1.000.000's images
What I planned to do:
Add a CDN & Load balancer to the Google Storage bucket to serve the images worldwide fast on a subdomain.
Status: This works. At least it serves the images.
Problems:
But I have the feeling that the architecture is not right as the Google App Engine can't be put behind the same load balancer & CDN to serve all the static content via this CDN. And I see no way to add the content caching headers. The documentation of Google says I should be able to add cache keys in the loadbalancer config. But I've been 10 times through this config and the back-end bucket config but no luck to find any. Also in the app.yaml of the Google App Engine you can't set this as the images are not servered via the App Engine....
So questions:
Is it logical in this setup to have a GAE and a separate load
balancer with a storage bucket with the images?
How do I add cache-control headers to the CDN/bucket config of Google Cloud CDN?
Assuming that the GCS bucket setup you already have in place allows you to serve an image via the CDN & Load balancer as you desire, let's say on a URL like gs://www.example.com/img.png then handling such request will already include all the required cache control.
If so then in your GAE app-provided pages, instead of referencing an image via a relative path to your site, like <img src="/static/img.png">, which would indeed require handling its own cache management inside the GAE app code, you could simply reference the image via its corresponding URL in the existing CDN setup: <img src="gs://www.example.com/img.png">, with all cache control already included.
Note: I didn't actually try it (I don't have such GCS CDN setup), but I see no reason for which this wouldn't work.
I like that Flash CC 2015 Canvas uses CreateJS, however it's not working in doubleclick as the CDN serving the .js files is being served http and doubleclick needs it to be served as https.
Is create JS aware of this and do they have updated CDN links that we can use when uploading html5 creative to doubleclick, sizemek or other ad networks?
Asset is not SSL-compliant. The following resources are
non-compliant: http://code.createjs.com/easeljs-0.8.1.min.js
http://code.createjs.com/tweenjs-0.6.1.min.js
Did you try removing the scheme http? All should be left is //code.createjs.com/easeljs-0.8.1.min.js. I got a similar complaint.
The security trick is to make all the http:// calls into https://. Just add the s.
Doubleclick now hosts CreateJS on their own CDN: https://support.google.com/richmedia/answer/6307288
Due to the irruption of RTB and Big Ad inventories, non secure protocol url are not allowed.
So, as said you could do both: // or http://
Also, for AdServers, many of them do not accept Folder structure. CreateJS creates an "image" folder for the assets, It is better if you have every asset at root level.
Using IIS6 on win2003, if I have an image server is it more efficient to serve up images as http than https? Also is it possible to serve up images as http on a webpage than is https.
Like if this html file: Secure.html is on a server that forces https to be used, but inside https://www.myultrahighsecurewebsite.com/Secure.html/
and I have a image like so:
<img src="http://www.notsosecureatall.com/imagecode/serveupanimage.aspx?id=1&auth=1" />
Is this a good way to serve up images? Is there a better way? Also I wanted to have a defacto site to serve up images so I don't have to push images as well as code and markup between development and live. Should the images or certain type of images like tiff, png, svg, etc... be on https vs http or does it matter?
If I do implement an image server or a page dedicated to keeping track of images, I just want an easy system to push images from development to my production environment without getting snagged on installation problems. But also not having to worry about customers having access to images until a version has been properly approved.
It will be more efficient from a CPU (client & server) and network point of view to use plain old HTTP. You'll avoid the overhead of TLS traffic and encryption/decryption of data.
The scenario (mixed HTTP/HTTPS) you present will often annoy a user though. You'll get a warning similar to "This page has unsecured content" (this is getting at the HTTP-only images).
See Loading http content on https website for more info (and additional gotchas) on the previous paragraph.
Are you sure that you need to worry about efficient loading of images? Don't overengineer this. Please share some more details if you've noticed that this is a problem.
My MVC project uses the default location (/Content/...)
So where this code:
<div id="header"style="background-image: url('/Content/images/header_.jpg')">
resolves as www.myDomain.com/content/images/header_.jpg
I'm moving my images files to S3 so now they resolve from 'http://images.myDomain.com' Do I have to convert all the links in the project to that absolute path?
Is there perhaps an IIS7x property to help here?
EDIT: The question seems to boil down to the specifics of working with IIS's Rewrite Module. The samples I've seen so far show how to manipulate the lower ends and query string of a URI. I'm needing to remap the domain end of the URI:
http://www.myDomain.com/content/images/header_.jpg
needs to become:
http://images.myDomain.com/header_.jpg
thx
I'm not sure I understand you correctly. Do you mean
How do I transparently rewrite image urls like http://www.myDomain.com/Content/myImage.png as http://images.myDomain.com/Content/myImage.png at render time?
Or
How do I serve images like http://images.myDomain.com/Content/myImage.png transparently from S3?
There's a DNS trick to answer the second one.
Create the 'images.myDomain.com' bucket, and put your content in it under the '/Content/' path. Since S3 exposes buckets as domains in their own right, you can now get your content with
http://images.myDomain.com.s3.amazonaws.com/Content/myImage.png
You can then create a CNAME record in your own DNS provider taking 'images.myDomain.com' to 'images.myDomain.com.s3.amazonaws.com'
This lets you link to your images as
http://images.myDomain.com/Content/myImage.png
..and yet have them served from S3 (You might also consider a full CDN such as cloud front.)
can I use CDN with images ? and if can then how to use it with upload from website to CDN server
Seems like there are a few options to accomplish this.
The first one would be using the CDN as Origin. In which case, there is already an answer with some advice.
The second option would be using your current website as Origin for the images. In which case you will need to do some DNS work that would look something like this:
Published URL -> CDN -> Public Origin
Step 1 - images.yoursite.com IN CNAME images.yoursite.com.edgesuite.net --- This entry will send all traffic requests for the images subdomain to Akamai's CDN edge network.
Step 2 - origin-images.yoursite.com IN A or IN CNAME Public front end for the images
So the way it works is that in step one you get a request for one of your images, which will be then sent via DNS to the edge network in the CDN (in this case Akamai HTTP only). If the CDN does not already have the image in cache or if its cache TTL is expired, it will then forward the request to the public origin you have setup to pull the file, apply any custom behavior rules (rewrites, cache controls override, etc), cache the content if marked as cacheable and then serve the file to the client.
There is a lot of customization that can be done when serving static content via CDN. The example above is very superficial and it is that way to easily illustrate the logic at a very high level.
Yes, and you can check with your CDN provider on the methods they allow for uploading,
such as
pull (CDN server download the files from your website/server)
or
push (sent from your website/server to the CDN server)
Example : automatic push to CDN deployment strategy
Do you mean you want to use a CDN to host images? And you want to upload images from your website to the CDN or use the website run by the company hosting the CDN to upload the images?
Ok, firstly yes you can use a CDN with images. In fact it's advised to do so.
Amazon CloudFront and RackspaceCloud's Cloudfiles are the two that immediately spring to mind. Cloudfiles you can upload either by their API or through their website and CloudFront you upload to Amazon's S3 storage which then hooks into the CloudFront CDN.
In common CDN setups you actually don't upload images to the CDN. Instead, you access your images via a CDN, quite like accessing resources via an online Proxy. The CDN, in turn, will cache your images according to your HTTP cache headers and make sure that subsequent calls for the same image will be returned from the closest CDN edge.
Some recommended CDNs - AWS CloudFront, Edgecast, MaxCDN, Akamai.
Specifically for images, you might want to take a look at Cloudinary, http://cloudinary.com (the company I work at). We do all of this for you - you upload images to Cloudinary, request Cloudinary for on-the-fly image transformations, and get the results delivered via Akamai's high-end CDN.