Good questions...

We are now using Cloudflare Pro. The reason for that is because we wanted to provide SSL connections to CDN resources. Some of our pages are served over SSL (profile management, private messages, registration and login). With Clouddlare Pro we can continue to serve this with *.geekzone.co.nz without much fuss - none at all.

Latency from the nearest POP (Sydney) seems good. A couple of Page Rules were created to make sure our Riverbed Aptimizer resources were cached properly, otherwise they would be requesting every resource from our origin server instead of serving from the cache.

Uptime is very good, never had a problem with that.

DNS settings had a small glitch when we added our IPv6 address, causing some of the domains to point to the wrong place. This was solved by removing our IPv6 address from their DNS, and using their own automated IPv6. Not sure if this was fixed, no need for us to test again.

There's a small problem with SSL connections and Chrome. Basically we wanted www.geekzone.co.nz to go through Cloudflare to take advantage of the web application firewall, DDoS protection, spam protection, etc. But Chrome users were seeing a high number of "Too Many Redirects" errors.

What we do here is that if a page *IS NOT* to be served over SSL then we do a 301 redirect to the non-SSL version. This is followed by the browser with a new request to the URL provided.

What I've seen is that Cloudflare was requesting HTTPS resources even while the browser was requesting a HTTP resource. When using Cloudflare we only see the requests coming from their datacentre, not from the browser. So we don't know what the browser is requesting, so we obviously would issue the 301 to tell the client to ask for non-HTTPS. The browser would ask for the HTTP and again Cloudflare would request HTTPS insteand. After a few of these, Chrome wouls say "enough" and through the "Too Many Redirect" errors.

I confirmed this was the case because I saw it happening to myself, and immediately looked at the logs for the unique session id and other cookies we use. I requested a page only I have access to and I could clearly see the log entries with the requests coming in via HTTPS when I only ever requested HTTP.

I have spent a few weeks explaining the problem, supplying log entries and examples from end users.

Their first responses was that it was a configuration problem on my side - suggested that we didn't have a SSL cert (which we do, a wildcard one), suggested we were not redirecting correctly (we are, the problem doesn't happen when serving from our server), suggested it as a SPDY problem (it is not, as we turned it off in the Cloudflare configuration for a couple of weeks and the problem still happened), even suggested our server wasn't coping with load (it is, we monitor it very closely).

At the end I just bypassed the www domain and now serving it directly from our origin server. This means we are using Cloudflare only as a CDN. We had to do this because Chrome is responsible for 35% of our traffic at the moment. It's huge for us.

After much discussion I was told by their support that this is a Chrome problem, which will be default request HTTPS if a domain has previously served HTTPS. I couldn't find any documented bug on this, and certainly have not seen this happening when serving directly from our servers.

I suspect the Cloudflare proxy is injecting HTTPS somewhere by mistake but can't do much since it seems there's not much interest in having this fixed - it's a "Chrome problem".

So, there it is. Mixed results. Very good CDN, including uptime, good DNS tools, good management pages, good pricing, but still not quite happy with their support.