I'm new to CloudFlare and I want to server images through them. (adserver).
Looking at my nginx access logs I'm getting multiple requests per hour.
But in the page-rules I've put:
and doing curl -svo /dev/null https://.... I get the right answer.
If you are wanting CloudFlare to serve and cache images, there's an easier way than using page rules.
By default, CloudFlare will cache static content, which includes images, CSS and JS files.
Knowing this, go to dashboard > domain > caching
The caching level will probably be standard, but read the details from the help dropdown.
Set the browser cache expiration to 1 month and then you are done.
Good luck!
Related
We are stuck with a non-trivial question with nginx.
Our web server (Nginx) has a cache enabled for all links.
When we do newsletter campaigns, each customer accesses our website using a unique URL and this means that the nginx cache is not used.
This results in a high load on the website every time we send a newsletter, so we need to deal with this in some way.
An example of link
https://www.example.com/deals/calendarraa?utm_content=calendars_link&xnpe_tifc=hFzDOFnDbuPsOfnDx9pZVjQsVuU_O.bpx.US4FzXxDxZ4.VdxDPuxuYj4nTT&utm_source=newsletter&utm_campaign=deals%2520offer%3A%2520calendar%2520and%2520greeting%2520cards&utm_medium=email
Is it possible to configure nginx so that in case we have params starting with utm_ &/or xnpe_tifc, e.g. we ignore these parameters and nginx serves website with URL without them?
That means: https://www.example.com/deals/calendarra? or even better just https://www.example.com/deals/calendarra
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
I currently use Akamai as a CDN for my app, which is served over multiple subdomains.
I recently realized that Akamai is caching CORS requests the same, regardless of the origin from which they were requested.
This of course causes clients that make requests with a different Origin than the cached response to fail (since they have a different response header for Access-Control-Allow-Origin than they should)
Many suggest supplying the Vary: Origin request header to avoid this issue, but according to Akamai's docs and this Akamai community post, this isn't supported by Akamai.
How can I force Akamai to cache things uniquely by Origin if an Origin header is present in the request?
I did some research, and it appears this can be done by adding a new Rule in your Akamai config, like so:
Note that if you do this - REMEMBER - this changes your cache key at Akamai, so anything that was cached before is essentially NOT CACHED anymore! Also, as noted in the yellow warning labels, this can make it harder to force reset your cache using Akamai's url purging tools. You could remove the If block, and just include Origin header as a similar Cache ID Modification rule too, if you were ok with changing the cache key for all your content that this rule would apply to.
So in short, try this out on a small section of your site first!
More details can be found in this related post on Stack Overflow
We have hosted an API on Akamai. I had similar requirement, but we wanted to use the cached response on Akamai for all the touchpoints. But without CORS settings, it used to cache the response from first origin, and then keep it in cache, and the following requests from other touch points use to fail due to cached origin header.
We solved the problem with using API Gateway feature provided by Akamai. You can find it under API Definition. Custom cache parameters can also be defined here. Please see the screen shot for the CORS settings. Now it cached the response from backend and serve to the requester as per the allowed origin list.
CORS Setting in API Definition
This question is specifically about page rules in Cloudflare, which allow you to specify wildcard patterns on your site using rules - and handle each pattern differently.
One of the patterns is "Force SSL" - in effect, any request that matches that pattern will be forced down the path of https:// - whether that's Flexible SSL or otherwise.
The problem with choosing this option is that all other options over the CDN/cache time, etc. disappear.
This raises some obvious issues to which I've found no clear answer:
If Cloudflare serves a https:// resource, does it still cache static resources?
How do I control the nature of the resources cached? In other words, the settings equivalent to "Simple" caching, and "Aggressive" caching.
Is there any ability to set options such as cache expiry, time that they reside on edge servers before expiration, etc?
Is it possible to set "Cache Everything" when serving requests over https://? It certainly exists on the http:// equivalent.
I would like Cloudflare to re-direct my visitors from http:// to https:// automatically as opposed to do it on my app, because the various apps on my domain (Wordpress included) have various quirks that make configuring each one both tedious and error-prone.
you can add another rule for caching for https - the first rule would be to divert all http to https with another rule right after that to handle the https traffic.
"If Cloudflare serves a https:// resource, does it still cache static resources?"
Yes. It doesn't matter if it is http or https://
What CloudFlare caches by default
"How do I control the nature of the resources cached? In other words, the settings equivalent to "Simple" caching, and "Aggressive" caching."
By using those settings in your performance settings.
"Is it possible to set "Cache Everything" when serving requests over https://? It certainly exists on the http:// equivalent."
I would actually recommend not doing cache everything, really. While it is an option that is available, you could have issues with users that have to sign in, etc.
"Is there any ability to set options such as cache expiry, time that they reside on edge servers before expiration, etc?"
You can set a browser cache TTL in your performance settings; we should also honor the expire headers you have set on your server.
we have nearly 13 domains within our company and we would like to serve images from one application in order to leverage caching.
for example, we will have c1.example.com and we will put all of our product images under this application. but here I have some doubts;
1- how can I force client browser's to cache the image and do not request it again?
2- when I reference those images on my application, I will use following html markup;
<img scr="http://c1.example.com/core/img1.png" />
but this causes a problem when I run the website under https. It gives warning about the page. It should have been used https//c1.example.com/core/img1.png when I run my apps under https. what should I do here? should I always use https? or is there a way to switch between auto?
I will run my apps under IIS 7.
Yes you need to serve all resources over https when the html-page is served over https. Thats the whole point of using https.
If the hrefs are hardcoded in the html one solution could be to use a Response Filter that will parse all content sent to the client and replace http with https when necessary. A simple Regular Expression should do the trick. There are plenty of articles out there about how these filters are working.
About caching you need to send the correct cache-headers and etag. There are several of questions and answers on this on SO like this one IIS7 Cache-Control
You need to use HTTP headers to tell the browser how to cache. It should work by default (assuming you have no query string in your URLs) but if not, here's a knowledge base article about the cache-control header:
http://support.microsoft.com/kb/247404
I really don't know much about IIS, so I'm not sure if there are any other potential pitfalls. Note that browsers may still send HEAD requests sometimes.
I'd recommend you setup the image server so that HTTP/S is interchangeable, then just serve HTTPS Urls from HTTPS requests.