How LexBlog uses Cloudflare's Page Rules

There are a number of ways to access this website. One might reasonably type any of the following into their address bar:

I’m using an image for this demo rather than typing out the urls, because our platform will automatically replace plain-http versions of the url with the https version.

In short, that’s the four permutations of http/https and www/non-www. They all work just fine, and they all end up sending you to the https/www form. In other words, no matter which one you use, you always end up at https://www.99parkrow.com .

Why does this occur? Why is this behavior desired? The answer to both questions has a lot to do with Cloudflare and our unique integration with it.

Enter LXB Cloudflare Tools and LXB Launch Wizard

Our platform uses dozens of custom plugins that we’ve created and improved over the years. Pertinent to this article are two of them:

LXB Cloudflare Tools, which provides our platform with an abstraction layer for managing Cloudflare settings.
LXB Launch Wizard, which provides our staff with a UI for escorting blogs through the life cycle of creation and launch.

Thanks to those two plugins, our blogs are automatically granted many helpful properties in Cloudflare. We’ll focus here on Always Use HTTPS and Forwarding URL. Taken together, those to settings are what cause any of the four urls demonstrated at the start of this article, to result in the https/www form.

Always Use HTTPS

It’s a good idea to have this in place so that users don’t send any personal information in an unencrypted state. Plain http traffic would be vulnerable to simple attacks like the ones demonstrated in this video.

Forwarding URL

rules — The *Forwarding URL* page rule causes non-www requests to forward to their www equivalent.

It’s a good idea to have this in place for two reasons:

SEO: Search engines might become confused about the intended difference between the www and non-www site.
Logging in: Browsers would store a login cookie for both the www and non-www, meaning you’d have to log in twice if you happened to access each version.

But Why Do this on Cloudflare?

The astute reader might be asking, “Hey LexBlog, you have many hundreds of blogs online. Why manage Cloudflare settings on all them when you could just install some code on your web host to do this?”

There is some merit to this point. Our Cloudflare integration amounts to a non-trivial piece of complexity that we have to maintain. And it would be very easy to just do this via code on our web server.

And guess what? We actually do enforce this functionality via code on our web server. It’s a redundancy in case Cloudflare gets misconfigured.

Then why do it on Cloudflare at all? Because we want to do as much work as possible “on the edge”. That’s a fancy way of saying, we want Cloudflare (which is essentially free with no practical rate limit) to handle all of this logic, rather than relying on our web server (where traffic and machine hours are very much associated with a billable usage limit). Also, because of Cloudflare’s amazing network, these operations are much faster on their “edge” than on our own web servers. If it can be done on Cloudflare, it should be done on Cloudflare.

Sounds Complicated.

In order to debug all of this, we can use the excellent Postman app, which allows us to see how urls work, step-by-step. See below, where the traffic is first routed from http to https, and then from non-www to www.

The plain http request is forwarded to https at the Cloudflare level.

The non-www request is forwarded to the www version, also at the Cloudflare level.

The end result of this is that our web server has to handle a mere fraction of the requests it otherwise would. It doesn’t have to lift a finger until Cloudflare is done forming the request into its final https/www version. This means a less expensive, more performant platform for all of our users.

One thing we’ll be taking a look at in the near term is consolidating this into a single rule, so that it would take just one move to get from http/non-www, to https/www.

Any Questions?

It’s been hard to avoid a bit of jargon in this post. My intention here has been to provide some “under the hood” time for those who are inclined. If you’re interested in learning more — or if you are a customer who provides their own Cloudflare account instead of using ours and you regret it upon reading this — contact us any time for more details about how and why this all works.