The Zephr CDN can implement decisions based upon either site features or entire HTTP requests. It has a multi-layer caching system designed to keep documents (HTTP responses), decision inputs, including user data, and user access models (entitlements, etc.) in-memory or in an edge-side store.
Site features are parts of an HTML document (like an article body, a video, a data table, etc.) which are annotated with HTML comments.
Consider the following HTML:
<html> <head>… </head> <body> <h1>A site!</h1> <nav>… </nav> <div class="page-wrapper"> <h2>Something interesting</h2> <article class="article-body"> <p>…</p> <img> <p>…</p> </article> <ul class="related-reading">… </ul> </div> </body>
In this case, one might want to make decisions about whether a visitor can assess the article body. To do that, you would wrap the following comments around the article. Usually, these comments would be implemented in a CMS template.
<head>… </head> <body> <h1>A site!</h1> <nav>… </nav> <div class="page-wrapper"> <h2>Something interesting</h2> <!-- BLAIZE_FEATURE article-body --> <article class="article-body"> <p>…</p> <img> <p>…</p> </article> <!-- BLAIZE_FEATURE_END article-body --> <ul class="related-reading">… </ul> </div> </body>
If this document were to be served through the Zephr CDN, the Zephr Feature comment would be picked up and Zephr would look for a corresponding feature rule to decide how to handle that part of the content.
Zephr Feature comments are used under the hood to break a document into a tree, which Zephr will traverse in real-time to manipulate the content. Zephr Feature comments can be nested and repeated but do need to be balanced, in terms of their opening and closing, much like HTML tags.
As well as manipulating parts of an HTML document, Zephr can apply a certain amount of control to any HTTP response by applying rules at the request level. Unlike feature rules, there is no need to apply comments or other markers into the content itself; Zephr uses a combination of path patterns, HTTP verb and a priority score to choose which (if any) request rule it will apply.
Request rules can be used to replace the response body, manipulate response headers and set the response status code.
How are rules executed?
The CDN carries out the following steps, asynchronously and not necessarily in this order:
- Fetch the document from cache or the origin;
- If the document is HTML, break it up by Zephr Feature comments and construct an in-memory tree of the document parts – this in memory tree gets cached by the ETag of the origin response;
- Traverse the tree, executing the relevant DSL for each node, transforming the content as appropriate;
- Choose the request rule with the highest priority that applies to the current request;
- Execute the request rule DSL and transform the headers, body and response code as appropriate;
- Return the transformed response to the client.