Dummy Origin: we test work of CDN

Before deciding to work with a CDN, I would like to make sure that it will do exactly what we expect from it. Of course, you read the documentation and discussed everything with the consultants in detail, but this is not enough? And if you approach the matter as corrosively as we do, this is not enough. You would like to test the CDN, get the objective characteristics of its work, compare them with your requirements, etc.

Dummy Origin is the tool that allows you to do all this in the best way, and most importantly - easily.

Dummy Origin is a dedicated server written in Go. It was designed specifically for testing CDNs operating in pull mode. It is easy, fast, easy to install, and most importantly - it is open source, that is, free!
')
Why use Dummy Origin instead of testing the CDN directly using your production server? Because it's easier to check the various modes of the proxy.

• You do not need to change anything in the configuration, server settings and sites.
• You can freely change the headers in the responses and analyze how the CDN responds to it.
• It is very easy to test various critical scenarios like “my server gives error 502, does the CDN support the distribution of outdated copies of pages during the offline of the main site?

Dummy Origin features

Main: Dummy Origin injects arbitrary headers into the request. This is done using the URL parameter string, which is then inserted as the request header. For example, send to the URL ?ETag="41a0544696e19971383984fdaaeb5aed" , Dummy Origin will give the ETag:"41a0544696e19971383984fdaaeb5aed" in the request header.

This mechanism allows testing the CDN behavior without changing the server configuration and rebooting it, which would be required to change the headers.

Other Dummy Origin features:

Opportunity	Description	Benefits
Gzip	Compresses the response using standard Gzip compression. Based on file extensions, not Content-Type. Currently supports .html, .css, .js, and .json extensions, but you can easily add the rest	Tests CDN operation with compressed files.
Conditional queries	Typically, the server issues a Last-Modified header along with a 200 response and issues a 304 or 200 if it receives an If-Modified-Since request	Allows you to check whether the CDN sends requests with a condition after the expiration date of the file in the cache
Range Queries	Sends the requested byte range in a 206 partial response and the corresponding Content-Length header	Important for transferring large amounts of data via a CDN, such as video files.
404 and 301	Returns error 404 if the resource does not exist, makes a 301 redirect if /index.html is requested	Does CDN 404 cache caches? Does CDN 301 transmit further or does it process the redirect itself?
Special error generator	When the server receives a request in the form of GET / err / <code>, it returns the http status <code>. The value of <code> should be in the range of 400 to 599	Allows you to test the behavior of the CDN in the event of a server issuing various errors. In particular, you can check if the CDN response caches 404.
X-tb-time	The server always shows the current time in the X-Tb-Time header.	Helps determine whether a CDN serves a query with data from a cache or from a server and how long the content is already in the cache.
Loggly support	Request and response details are processed via Loggly if the environment variable LOGGLY_TOKEN is defined.	Loggly is a cloud service for processing logs, very convenient for parsing logs of CDN requests to the server

In Dummy Origin today is not:

• Https
• Brotli (compression algorithm used in particular in the Chrome browser)
• Cannot issue various content / headers based on requests with User-Agent or Accept-Language headers.

Installation and configuration

Server installation is described in README.md on GitHub

Place several files on the server. They should be similar to the files that will represent your real content. Several images of different sizes, text files - scripts or just text. Some kind of video.

Do not place on the server index.html to see which files are in it by viewing the source domain in the browser.

Configure the CDN. Set the CDN option to distinguish addresses with different query strings as unique (i.e. distinguish file.jpg?123 and file.jpg?456 , in Airy.rf this is the option "Cache with query string"). Usually this mode is set to CDN by default, but still check. Also ensure that the CDN forwards all headers from the source server to the client, including the X-Tb-Time header.

Configure DNS. Also set a low TTL value on the server for about 300 seconds, which will come in handy later when testing the CDN response to no response from the server.

CDN Behavior Testing: Examples

Here dummy.mydomain.com address is used as the CDN address and dummy.origin.com is the address of the source server. Test using cURL. Run cURL with the following options: curl -vo / dev / null and send a GET request, and see only headers in response, sending the main body of the page to / dev / null.

Do not use the –I flag to send a HEAD request. A CDN can handle HEAD requests in a completely different way than GET. In addition, your users are unlikely to send HEAD to the server, their requests will be mainly GET.

Do not cache and retrieve all data from the source server.

This is not the most typical example of using a CDN, but if you need to leave some of the content uncached, you need to make sure that everything works as it should. The question here is which Cache-Control directive would be more appropriate to use. Based on RFC 7234, it seems logical to use Cache-Control: no-store. RFC writes:

The no-store directive indicates that data should not be cached for both the request and the response. Applies to both the public cache and the local cache.

Let's try:

 curl -vo /dev/null 'http://dummy.mydomain.com/15kb.jpg?Cache-Control=no-store' 

Below you see the response headers for our CDN Fastly tests. Surprisingly, Fastly does not respect the no-store and caches data after it does not detect it during the first request in its cache.

 HTTP/1.1 200 OK Access-Control-Allow-Origin: * Cache-Control: no-store Content-Type: image/jpeg Last-Modified: Tue, 21 Mar 2017 10:13:25 GMT X-Tb-Time: 2017-03-30 14:39:11.358951299 +0000 UTC Content-Length: 15887 Accept-Ranges: bytes Date: Thu, 30 Mar 2017 14:39:23 GMT Via: 1.1 varnish Age: 12 X-Served-By: cache-ams4136-AMS X-Cache: HIT X-Cache-Hits: 1 X-Timer: S1490884763.605627,VS0,VE0 Vary: Accept-Encoding 

Maybe it will work no-cache or max-age = 0? We want the CDN not to cache the responses and not send conditional requests to the source server.

Testing showed that no-cache does not work either - CDN continues to cache responses, but max-age = 0 worked.

Cache for 300 seconds, then check with the original

Writing a CDN to cache a file for 300 seconds is quite simple: Cache-Control = max-age = 300. The question here is this: when the file’s life time in the cache expires, what type of request will the CDN be sent to the server - conditional or unconditional? Someone may say that the conditional request here will be optimal, because if the file is not out of date, the server will say 304 - “no, the file is not out of date, you can take it from the cache”, and CDN will quickly give the client a copy of it. This is faster than if the server began sending the entire file itself.

RFC 7234 does not state that a CDN should send a conditional request to verify cache validity. Therefore, it will not be surprising if the CDN sends an unconditional request in this situation (which is not very good for performance).

 curl -vo /dev/null 'http://dummy.mydomain.com/15kb.jpg?Cache-Control=max-age=300' 

Fastly and CDNetworks send conditional requests. Airi.rf and StackPath sends unconditional requests to the server, updating the cache with a new version of the file. This can be seen from the source server logs and from the X-Tb-Time value of the field in the CDN client response header. Cache-Control = max-age = 300, must-revalidate was also tested, but without success.

 HTTP/1.1 200 OK Date: Fri, 31 Mar 2017 11:20:16 GMT Content-Type: image/jpeg Content-Length: 33956 Access-Control-Allow-Origin: * Cache-Control: max-age=20,must-revalidate Last-Modified: Fri, 31 Mar 2017 09:49:42 GMT X-Tb-Time: 2017-03-31 11:20:16.091275242 +0000 UTC Server: NetDNA-cache/2.2 Accept-Ranges: bytes X-Cache: EXPIRED Connection: keep-alive 

Cache for 5 minutes, allow issuing an expired version for another 15 minutes

 curl -vo /dev/null 'http://dummy.mydomain.com/15kb.jpg?Cache-Control=max-age=300&stale-while-revalidate=900&stale-if-error=900' 

Here it is important to test three situations:

1. Source server not found DNS (NXDOMAIN)

A long time after the DNS TTL expired in the cache for our server, the CDN still gave out the content it had saved. It's good.

More interestingly, the CDN continued to access the source server for fresh versions of the content. It seems that, together with the content, it also stores the IP addresses from which it was obtained, and thus the DNS error was “covered up”, which led to the impossibility of calculating IP. Or maybe Fastly supports long-lived connection with the server? Here we must look deeper.

2. The source server responds with 400

Something went wrong on the server, and he started to generate an error 400 Bad request. The CDN was expected to handle a stale-if-error in this case, but it simply translated the answer to the 400 client. As it turned out, the expectations were wrong, since RFC 5861 "HTTP Cache-Control Extensions for Outdated Content" states:

An error is a situation in which a 500, 502, 503 or 504 HTTP response is returned.

A 400 is not an error, by default.

3. The server drops all incoming traffic.

In the third scenario, the server's DNS records were replaced by tying the domain to the address 72.66.115.13. This address is associated with blackhole.webpagetest.org. This is a special address for testing situations when the server does not respond to any request.

Has the CDN started to publish the content stored on it? No, it began to give a response 503 after about 1 second of waiting, and this 503 answer contained the Retry-After header: 0. Iry.rf in the described situation replies with Retry-After headers: 500 and has customizable connection timeouts and response from the site hosting .

This is what is inherent in the default settings for the proxy. The documentation says: “If Varnish cannot contact the source server for any reason — in any case, a 503 response is generated.” This property is inherited from the Varnish code, on the basis of which most CDN proxies are created.

StackPath in a similar situation may provide archived content, but this situation must be configured by the user for errors 404, 502, 503, etc. However, the StackPath does not handle the situation of NXDOMAIN or blackhole.

So use Dummy Origin to make sure your CDN provider is working properly. This is a free open source tool.