We use a service, Imgix, that serves images in the most appropriate format for the client that requests them. So, if the request for a JPG comes from Chrome, it will send a WEBP image. If, it's from Safari, it will use JPEG2000.
We also use Akamai as CDN, so Akamai sits between users and Imgix.
If the first request for an image is from Chrome, Akamai will cache the WEBP format, and any future requests for the same image will receive a WEBP image, that means Safari users won't be able to view that image, because it's not compatible with the WEBP format.
Is it possible to configure AKAMAI to cache different images based on the format?
With Akamai, you can always set custom caching rules based on filename, path, file extension, or almost any other criteria you can think of. It's all handled as a Rule in your Property. Simply set the Match for what you want the caching rule applied to, and then set the Caching Behavior.
Related
Is it possible to serve always stale/cached data from CDN edge servers like Akamai. ?
Reason is if there is some problem in origin server and It might need 2-3 days to solve it.My origin server responds properly but I don’t want it to get overloaded and want CDN to keep serving the cached data instead for sometime.
Best Regards,
Saurav
Yes, Akamai can serve stale content if the request to the origin times out or produces an error code. Here's a screen shot of the "Caching" and "Cache HTTP Error Responses" behaviors.
Note, however, that your content will need to be fairly popular to remain in cache. If it's not popular, then it may be evicted before you're able to repair your origin.
A better alternative is to implement a Site Failover ruleset which allows you to serve your page with alternate content from a separate origin, or static assets from Akamai's NetStorage. Here's a screenshot of a typical Match of a failed origin and the standard Fail Over behavior.
The "Action" field provides the following options, which can each be configured to your needs:
Serve stale content
Redirect to a different location
Use alternate hostname in this property
Use alternate hostname on provider network
Serve alternate content from NetStorage
We have a use case where we are storing our images in a CDN. Let's say we are storing a.jpg in the cache and if the user uploads a newer version of the file, then it will flush the cache and overwrite the a.jpg. Now the challenge is that the browser might have cached the file. Since we cannot flush the cached image in the browser we are thinking of using one of the 2 approaches mentioned below :
Append a version a_v1.jpg, a_v2.jpg (version id is the checksum) this will eliminate the need for flushing the browser and CDN cache. I found a lot of documentation about this on the internet and so many people are using this.
Use the etag of the file to find eliminate the stale cache in the browser. I found that CDN's support etags but I did not find literature that etag is used for images.
Can you please share your thoughts about using etag header for cache busting ? Is this a good practice to use it ?
well i wouldn't suggest etag. This might have its advantage but has its setbacks as well. Say you are running two servers then the etag when content served from each of these servers might change.
Best thing i would suggest is control what the browser is caching and how long.
What i mean is send expiry headers when sending response from cdn to client browser say 5min TTL. This way browser will respect the expiry header. And once expired browser will send a fresh request to cdn when the page is refreshed.
When trying to use a font file from another domain on a web page, I ran into the restrictions of the Cross Origin Resource Policy in all its glory.
So, instead of referencing the external font URL directly from CSS with #font-face, I referenced a local URL path which redirects to the external font resource. I thought the browser might treat the font as a same-domain resource. And indeed, the redirect seemed to fool Chrome into using the external font, but this was not the case with Firefox, which did not allow it.
My question is, which of the two behaviors, demonstrated by Chrome and Firefox respectively, is the standards-compliant one?
From: http://www.w3.org/TR/cors/#cors-api-specification-redirect
Since browsers are based on a same origin security model and the
policy outlined in this specification is intended for APIs used in
browsers, it is expected that APIs that will utilize this policy will
have to handle a same origin request that results in a redirect that
is cross-origin in a special way.
For APIs that transparently handle redirects CORS API specifications are encouraged to handle this scenario transparently as well by "catching" the redirect and invoking the cross-origin request algorithm on the (cross-origin) redirect URL.
From what I can understand, it seems that Firefox handles it 'the right way'.
I have an web application in which I generate a download link to an external google resource. This request usually needs a cookie. Because of the cross domain policy I currently download the files with curl and then pass them through to the user. Now those files are large. So I was looking for a way to download them directly through the clients browser.
Playing around I've found out that I can append the cookie in question to the http query, but this only works if no other cookies are set! Since it's google almost all users will have set some cookies for .google.com. Is there any way (maybe some security feature or bug) I can trigger a download request for that file in the users browser without sending any cookies along.
I discovered that I can make a request to *.google.com. (notice the . at the end) and then most browsers won't send any cookies set for .google.com . I've did a quick test using browsershots and on my own devices. The hack works in almost all browsers except for Safari (desktop and mobile) and some no name browsers.
While this works, I've decided not to use that method because the file name will be set to something unusable (no file extension).
If I'm using a CDN to deliver images on an image-heavy page and I'm using a set of CNAME records pointing to the same CDN domain for faster loading, will images served (and cached by the browser) from one alias by found in the browser cache when served from another alias?
More simply, if cdn1.example.com and cdn2.example.com point to the same domain, will a browser be smart enough to load an image served from cdn1.example.com from the cache when subsequently called from cdn2.example.com?
My understanding is that this scenario will work.
Thank you!
No, it won't work. Browsers cache resources on the basis of their URLs. If the URLs are different, caching doesn't work.
See "Serve resources from a consistent URL" in Page Speed's recommendations.
You should use the same domain shard for each image. Depending on your backend technology, implement a simple function that computes the domain number based on the image name. A simple solution is hashcode(imageName) % n where n is the number of domain shards. This way, you don't have to remember which image falls under which domain bucket.