Well, the obligatory counterpart:
On the other side http://www.bbc.co.uk is similar, but co.uk is sort of the ".com" of GB.
Edit: Looks like the tag <meta http-equiv="refresh" content="0"> will trigger an immediate client-side refresh. Why do browsers support this?
I myself prefer non-HTTPS over CloudFlare for sites like this. As for best practice:
> Back in 2003, Lee Holloway and I started Project Honey Pot as an open-source project to track online fraud and abuse. The Project allowed anyone with a website to install a piece of code and track hackers and spammers. We ran it as a hobby and didn't think much about it until, in 2008, the Department of Homeland Security called and said, 'Do you have any idea how valuable the data you have is?' That started us thinking about how we could effectively deploy the data from Project Honey Pot, as well as other sources, in order to protect websites online. That turned into the initial impetus for CloudFlare. -- Matthew Prince, CloudFlare CEO
P.S., About cookies: Don't use cookies, LocalStorage is much better.
Source? Not saying I agree or disagree, but a statement like that without any supporting arguments or discussion isn't particularly helpful.
In short: LocalStorage is supported by all browsers, has no security issues as cookies have, has much bigger storage limit, much more handy API and don't need to be send on each request.
Further, a common method to reduce the risk of this is to place purely static public assets and user-specific private data on different domains.
> Further, a common method to reduce the risk of this is to place purely static public assets and user-specific private data on different domains.
In other words, "don't use CDN when you need cookies", fine.
There is no issue using CDNs with cookies.
Technically, they are reverse proxies with a focus on caching, however that is not all they do. You can use them for various other features like security and front-end optimization and they work fine with cookies.
It's common to use a CDN for the entire site - caching static files at the edge while sending page requests to the origin server with all the cookies, especially important as many sites are now dynamic and customized to the individual. There is no issue in using a CDN to proxy all requests.
If you need to authorize every single request (even to a static file) which means that every single request is unique, then this is obviously not a good use case for an edge server cache. You can still cache things in the browser with cache headers and continue using the CDN to proxy the full request with cookies to the origin. This doesn't add much latency and can sometimes decrease it because the CDN will keep faster connections open to the origin.
However, most CDNs today also offer their own access controls either with cookies or url tokens so you can do authorization at the CDN edge instead of the origin.
And yes, you can use the CDN to cache static files and just proxy requests to pages. Usually private information that requires authentication is in the webpage and the static files like javascript, css and images dont need protection.
You can still use a CDN in this case however, by default files with cookies cannot be cached on a CDN's edge servers. Some CDNs have the ability to exclude the cookie from the static file such as KeyCDN which allows you to ignore the cookie and/or strip it entirely (https://www.keycdn.com/support/pull-zone-settings/). This ensures that your file is now cacheable which is important for instance if you are using Cloudflare which adds a Set-Cookie header to domains routed through them.
And actually it's advantage of local storage, because of less amount of garbage traffic.
There are lots of uses for cookies without having JS or a full browser available.