Increasing Cache Hit Rates with Query String Sort

Optimized Performance: Increasing Cache Hit Rate

At CloudFlare, we care a lot about serving requests as fast as possible. Files can be served much faster when already in CloudFlare’s cache. Skipping the trip to the customer’s web server eliminates the latency of that connection and saves bandwidth from the connection between CloudFlare and the customer’s origin, and allows us to utilize the full speed of our ultra-fast servers.

By default, CloudFlare only caches static files. However, Page Rules can be utilized to set more files as cacheable. For more information on Page Rules, please see the Page Rules section of our knowledge base.

Items are cached by their full URL, including the query string. However, due to the details of how query strings work, this can lead to some cache misses. There is no RFC which defines that the order of query strings arguments matter, but in some (rare) cases they do. Thus, by default, CloudFlare caches the following two requests separately:

https://example.com/a?color=red&word=hi https://example.com/a?word=hi&color=red

Introducing Query String Sort

With a newly available Enterprise-level feature called Query String Sort, CloudFlare will first sort the query strings in a URL into a deterministic order before checking cache Continue reading

Protecting web origins with Authenticated Origin Pulls

As we have been discussing this week, securing the connection between CloudFlare and the origin server is arguably just as important as securing the connection between end users and CloudFlare. The origin certificate authority we announced this week will help CloudFlare verify that it is talking to the correct origin server. But what about verification in the opposite direction? How can the origin verify that the client talking to it is actually CloudFlare?

TLS Client Authentication

TLS (the modern version of SSL) allows a client to verify the identity of the server it is talking to. Normally, a TLS handshake is one-way, that is, the client is able to verify the server's identity, but the server is not able to verify the client's identity. What about when both sides need to verify each other's identity?

Enter TLS Client Authentication. In a client authenticated TLS handshake both sides provide a certificate to be verified. If the origin server is configured to only accept requests which use a valid client certificate from CloudFlare, requests which have not passed through CloudFlare will be dropped (as they will not have our certificate). This means that attackers cannot circumvent CloudFlare features such as our WAF Continue reading