Sign up

Select your solution package

First, you have to choose the solution that best meets your needs from the following options:

Advanced

Business

Contact and billing information

In this second step, you can enter a promotional code or voucher in the space provided in the contracted services summary. You then have to fill in the following contact information:

Full name

Email address

This email address will be Transparent Edge’s main means of contacting you. So it’s essential that the email address you give us is valid, that you have access to it, and—very important—that you check it often. Plus, this email address will be your username when you log into the platform.

Web page

Once you have completed the registration process and you log in to Transparent Edge’s self-service dashboard, you will see that the domain (site) you entered has been added to the settings of your brand-new profile. Of course, you are free to add as many new domains as you need or delete any that are no longer necessary.

Password

To continue with the registration process, you have to enter a password with at least eight characters that contains one uppercase letter, one lowercase letter, and one number.

After filling in your contact information, fill in the fields with your billing information:

Company name

Tax ID

Your company’s tax ID code (CIF in Spain) or your personal tax ID number (NIF in Spain).

Address

You have to fill in all the fields to be able to continue with the registration process.

Once you've entered all the required information into the form, you’ll have to click the checkbox to accept the terms and conditions of use for the platform. You’ll also have to click the checkbox for the terms and conditions of the contract.

Payment authorization

Finally, you’ll have to confirm the payment authorization. To do so, you’ll be redirected through Transparent Edge’s gateway and you’ll have to enter your credit card data.

You will be charged at the end of each month based on the support package you purchased as well as your consumption.

If your payment method is rejected by the gateway, you’ll see an error message and be redirected to the registration form where you can verify the information you entered previously and fix any errors.

User account activation

Once you have completed the registration process, you’ll have to activate your brand-new account. To do so, click on the “VERIFY YOUR EMAIL” link in the welcome message you receive in your inbox.

This welcome message is automatically sent to the email address you entered in the registration form once you have completed that step. You’ll then have 48 hours to confirm your email. You won’t have access to Transparent Edge’s self-service platform until your account is activated.

That email will also tell you Transparent Edge’s CNAME (Canonical NAME) so you can note it and adjust the DNS.

For instance, our assigned CNAME record would be: caching.cNNN.edge2befaster.net.

In addition to the CNAME, it's important for there to be a «tcdn.txt» file in the root directory of your website with the content of the activation email.

This guide is intended to help you start using Transparent Edge as quickly as possible.

About Transparent Edge

Sign up

Your first configuration

We’d be more than happy to help you.

So now what?

Brotli Compression is an open-source compression algorithm developed by Google. It is used to reduce file size.

An API is a set of routines, protocols, definitions, and tools for developing and integrating application software. APIs specify how the software components interact and they are used for GUI (Graphic User Interface) components.

A cache key is how the CDN saves an object to its cache. By default, the cache key is made up of:

[Host header] + [url] + [Query Stream]

From there, we can complicate the cache key as much as we wish, adding more elements to save more versions of the same object. Let’s look at an example:

https://www.transparentedge.eu/index.html?param=1
​
https://www.transparentedge.eu/index.html?param=2

For Transparent Edge—and generally, for any other system of HTTP caches—these are distinct objects. Therefore, even if the first one is cached, it will download again to the origin when the second one is requested because in the CDN cache they are distinct objects.

https://www.transparentedge.eu/index.html?param=1

And a Vary header like this:

Vary: User-Agent

We can make the CDN cache save as many objects as the number of user-agents requesting them.

In the previous example, the cache would save one object for each distinct user-agent (there are many). This would render the cache system ineffective. That’s why we don’t recommend having a Vary header with a user-agent or cookie value. It could be interesting, however, to have an X-Device value, to be able to serve different versions of an object depending on the type of device requesting the resource.

This section contains all the basic concepts about our service that you should understand before you begin:

We have created a catalog of key terms that appear throughout this documentation to help you better understand our service.

Caching is the process of storing data in a cache. A cache is a temporary storage space. One example are the files that are automatically requested when you look at a web page, and that are stored on the hard drive in a cache subdirectory of the browser directory.

Cache-control is an HTTP header used to specify browser caching policies, in both client requests and server responses.

Policies include how and where a resource is cached and its maximum age before expiring.

Cloud computing is a generic concept used to describe the hardware and software available through the Internet for storing and accessing data and programs through the network rather than on the hard drive of a computer. In this context, the cloud is the Internet itself.

Cloud computing architecture includes all the components and subcomponents required for cloud computing. These components typically consist of a front-end platform, back-end platforms, a cloud-based delivery, and a network.

Dynamic Adaptive Streaming over HTTP (DASH)—also known as MPEG-DASH—is an adaptive bitrate streaming technique that enables high-quality streaming of multimedia content over the Internet delivered from conventional HTTP web servers. MPEG-DASH works by breaking the content into a sequence of small HTTP segments. Each segment contains a short interval of video/audio and there are multiple different segments for each bitrate.

When the content is played by a MPEG-DASH client, the client automatically selects the segment with the highest possible bitrate.

In the context of the CDN, an edge server is a server whose main purpose is to serve content as close as possible to the person requesting it, reducing latency, load times, and bandwidth consumed. These servers are typically located at the logical extreme of a network, providing an entry point into the network or allowing communication between different networks.

The concept of cloud services encompasses any service available through the Internet from the server of a cloud computing provider.

A CNAME is a type of DNS record that maps one domain name (an alias) to another (the canonical name). The CNAME record always points to another domain name, never to an IP address; this second domain is ultimately what points to the IP address of the resource being accessed.

A data center is a facility that houses computer systems like servers, routers, switches, and firewalls, as well as other components like backup equipment and fire-suppression and air-conditioning systems. Data centers store, process, and distribute data to authorized persons and incorporate data into processes so they can be consulted and/or modified.

IaaS (Infrastructure as a Service) is a cloud computing model in which all the services of an infrastructure are provided through the Internet. This lets you manage all the applications, data, and operating systems while your provider manages the virtualization, the network, the storage, and the servers.

IaaS means you don’t have to maintain your own data center, with everything that involves, or worry about updating and physically checking all the equipment—the provider takes care of all that.

Normally, the user manages the infrastructure through a web panel or an API, making it easy to scale, update, and add new resources whenever necessary.

GSLB (Global Server Load Balancing) is a method of distributing Internet traffic to a network of servers in different geographical locations. GSLB ensures that requests are correctly distributed and that they take into account the location of the person using them, improving latency and preventing a single server or group of servers from carrying the entire weight of the traffic.

The ETag or entity tag is one of the mechanisms that HTTP provides for web cache validation, which allows clients to make conditional requests. This allows caches to be more efficient and saves bandwidth, as a web server does not need to send a full response if the content has not changed.

HLS or HTTP Live Streaming is an HTTP-based adaptive bitrate streaming communications protocol developed by Apple Inc. as part of its QuickTime, Safari, OS X, and iOS software. It works similarly to MPEG-DASH in that it also breaks the stream into small HTTP-based downloadable segments.

A list of available streams, encoded at different bit rates, is sent to the client using an extended M3U playlist. Because it is based on HTTP, this protocol can traverse any firewall or proxy server.

The Last-modified header is an HTTP response header that contains the date and time when the origin server believes the resource was last modified.

It is used as a validator to determine if the resource is the same as the previously stored one. It is less accurate than an ETag header, but it can be a fallback mechanism.

Conditional requests containing If-Modified-Since or If-Unmodified-Since headers make use of this field.

An Internet Exchange Point (IXP) is a physical infrastructure used by Internet Service Providers (ISPs) to exchange Internet traffic between their networks. Its primary purpose is for the networks to be able to connect to each other directly through an infrastructure rather than having to do so through a third-party network. This decreases the portion of traffic, reducing the average per-bit delivery cost of the content.

Multi-CDN is the strategy that combines several existing CDN providers into one large global network. This strategy dynamically optimizes and unifies the leading network infrastructure and cloud providers across the globe to quickly, safely, and reliably accelerate web content, no matter where users are located.

HTTP/2 is a major revision of the HTTP protocol that enables more efficient use of web resources. It is compatible with HTTP/1.1 and does not involve significant changes to basic concepts like HTTP methods, header fields, and status codes.

It does however include countless improvements, like the use of a single connection, the compression of header fields, and the server push or cache push service that enables the server to preemptively push information to the client before the client requests it. So, for instance, when an HTML page is requested that is linked to style sheets, images, and other resources, everything is sent together in the first request (multiplexing) rather than having to wait to parse the HTML file.

A NoSQL is a database that does not use the SQL language to query and define data. The definition often encompasses various non-relational databases that lack tables and tabular relationships, where information is structured so as to give the system good horizontal scalability (adding more servers). The most common examples are for document storage or key-value systems.

An OTT or over-the-top is a media service offered directly to viewers via the Internet, bypassing the cable, broadcast, and satellite television platforms that traditionally control and distribute content.

The term mainly applies to subscription-based video-on-demand services that offer film and television content.

PaaS or Platform as a Service is a delivery method in cloud computing that is halfway between Software as a Service (SaaS) and Infrastructure as a Service (IaaS).

While IaaS provides infrastructure only, PaaS goes a step further and provides a bundle of software tools to design, test, review, and launch the product.

PaaS providers host hardware and software on their own infrastructure. Transparent Edge fits into this framework.

A PoP (point of presence) is a physical point where a service provider has equipment. It can include everything from a single server to an entire data center.

PoPs are where the edge servers that make up a CDN’s global network are located. The number and location of these PoPs have a great impact on the CDN’s coverage and performance.

Load balancing is a way to distribute network traffic across multiple servers that uses balancing methods to improve the overall response time and availability of applications. It ensures equal distribution so that no one server has to handle too many requests.

There are several balancing methods or algorithms:

• Least connections: Directs the traffic to the server with the fewest active connections.

• Least response time: Directs the traffic to the server with the fewest active connections and the lowest average response time.

• Round robin: The traffic rotates through the available servers, which can be useful when the servers all have equal value and don’t require persistent connections.

• IP hash: The client’s IP address determines which server receives its request.

When we talk about the origin, we're referring to the web servers that host your website. These servers can be in a single data center or in several. They can be in the cloud or on-premise. The only thing Transparent Edge needs for an origin to be valid is for it to respond via the HTTP protocol (with or without SSL) and via the port of your choosing (usually 80 or 443).

A private cloud is a computing model in which IT services are provided to a single organization through a private IT infrastructure. They are usually managed using Internet resources.

A private CDN is a CDN that only serves content to its owner. It consists of PoPs that can be caching servers, reverse proxies, or application delivery controllers. It can be as simple as two caching servers, or architecture large enough to serve petabytes of content.

A public cloud is a type of computing service that providers make available to anyone over the Internet. It can be a free service or sold on demand. Some providers offer clients a pay-as-you-go model based on their use of the CPU, the storage, or the bandwidth.

To purge means to invalidate content. When we work with cache systems, it’s often necessary to invalidate content and force the caches to go to the origin server for a new copy.

Origin shield is an extra caching layer of the CDN that sits between the edge servers and the origin server. It is also known as second-level edge or layer 2.

It acts as a funnel, preventing the origin server or servers from receiving requests from multiple edge servers.

The query string is the part of a URL that contains the data to be sent to the web application. It generally includes fields added to the base URL by the client application, for example as part of an HTML form.

www.ejemplo.net/web.php?campo1=valor1&campo2=valor2

The example above is for a dynamic website. In this case, the server automatically creates the response page when the browser requests it, using the data that appears in the URL.

There are other methods of generating dynamic pages, such as separating the query strings using the “/” character. The server configuration lets us generate friendly URLs, like the one below:

www.ejemplo.net/main/blog/132

In this case, the name of the variable is predefined on the server based on the variable’s position in the URL, and the content of the variable is its value (main, blog, 132).

A reverse proxy is a type of proxy server that sits between the client and the server on a network infrastructure. It manages incoming requests, interacting with the server on behalf of the client. This provides an additional layer of abstraction because the client never learns of the characteristics or existence of the server or servers, instead communicating directly with the reverse proxy.

A reverse proxy is often used for safety, load balancing, caching, optimizing load times, etc.

Software as a service is a software distribution model in which the software is available through the Internet (cloud-based applications) instead of being installed locally. In this case, the service provider hosts all the infrastructure required for the application to run and the client merely makes use of the software’s functions.

Software-defined storage is a storage architecture in which the storage management software is decoupled from its hardware. It’s generally conceived to run on any x86 system or sector standard, so that software does not depend on any proprietary hardware.

The TCP (Transmission Control Protocol) is one of the main protocols of the Internet protocol suite. It originated in the initial network implementation and complements the Internet Protocol (IP). Together they form the TCP/IP model.

A status code is an HTTP or HTTPS response code used by the server to let the client know the status of a request and whether or not it was successful.

Successful response

200 OK

206 Partial Content

The server is only delivering part of the content. This type of response is given to range requests when the client explicitly requests part of an object using the Content-Range header.

Redirections

301Moved Permanently

This status code indicates a permanent redirection. This type of request can be cached by proxy cache and by browsers. They must be used carefully because they can cause confusion.

302 Found

This is used to identify a temporary redirection, so it’s never cached in proxies or browsers.

304 Not Modified

This indicates that the content has not been modified on the server. It is sent as a response to requests from browsers and proxies to client web servers with the If-Modified-Since header.

Client errors

400 Bad Request

We see this type of error when the server can't process a request sent by the client. It’s not generally seen in browsers and is more often seen when processes or applications make their own HTTP requests. It’s usually due to a poorly formed request.

401 Unauthorized

Sometimes a website or part of it is protected under a username/password and this status code warns us of unauthorized access. Requests with authentication are not cached in Transparent Edge.

403 Forbbiden

This tells us we are entering a restricted part of the website and our access is denied, possibly for security reasons. It may be due to an IP restriction or because a prohibited action is being attempted to exploit a vulnerability of the web application. In Transparent Edge, the latter only occurs if you have the Secure Layer.

404 Not Found

This type of error is very common. It simply means that the web resource we are requesting cannot be found on the server.

405 Method not Allowed

This status code is returned when the client makes an HTTP request using a protocol not supported by the cache or server. Transparent Edge allows the following methods:

GET
POST
PUT
DELETE
OPTIONS
PROPFIND
PUSH
HEAD

408 Timeout

Errores de servidor

500 Internal Server Error

This indicates a server error, generally with the application. For instance, it can occur when there are unclosed quotation marks in PHP.

502 Bad Gateway

This is a code returned by some web servers when acting as a reverse proxy and the resource behind them is not available. It’s very common with Nginx.

503 Service Unavailable

The service is not available. This error is returned when there’s no contact with the client’s web server, either because it’s down or due to a communication problem. It's generated “on the fly” by Transparent Edge when the client has a fatal error. When 503 error messages are received by the client, look for errors in its logs.

504 Gateway Timeout

This response code typically occurs when the client’s origin server is taking too long to return a non-cached object, either because it should not be cached or because it has expired.

TLS (Transport Layer Security) is a security protocol defined by the IETF (Internet Engineering Task Force) to replace SSL 3.0 (Secure Sockets Layer 3.0). Like SSL, TLS uses digital certificates for user and network authentication.

In reference to the CDN, TTL (time to live) is the amount of time an object is cached. The cache system takes different factors into account to determine the lifetime of an object. Correctly configuring these parameters will guarantee the cache works correctly, avoiding unnecessary use of resources and ensuring an optimal user experience.

Round-trip time is the time it takes, in milliseconds, for a network request to go from a starting point to a destination and back again.

Time to first byte or TTFB is a measurement used to determine the responsiveness of a network resource like a web server or any other type of element. In the web environment, it refers to the time between when a user makes an HTTP request and when the first byte of the page is received by the client’s browser.

A virtual machine is software that emulates a computer system. Virtual machines can run programs or full operating systems.

There are two major categories of virtual machines:

• Process virtual machines: These run as a process inside the operating system by interpreting between the source code and the machine code to run the application, independent of the hardware platform and the operating system. The clearest example is the Java Virtual Machine.

What's a web cache?

A web cache is simply a system that lets us store HTTP objects dynamically.

A web cache can be found on the client side (web browsers) or on the server side (intermediate proxies or web servers).

These systems significantly improve performance in terms of loading HTTP objects, reducing the load times of web pages and thus optimizing the end-user experience.

The system works by saving local copies of the web objects requested by browsers, so that when the browser requests an object that's in the cache, it is served directly from there without needing to go back to the destination server to generate the object again, saving time.

What is a CDN?

A CDN is a content delivery network. In basic terms, a CDN is a system of geographically distributed caches that can serve content from the cache server nearest to any end user’s location. This reduces network latency and page load times.

Many people think that CDNs are only used to reduce network latency and bring content closer to end users, but that’s not the case. The true potential of a CDN—and what really enables it to improve load times beyond network latency—lies in its caching techniques: serving a cached object from memory is infinitely faster than generating a web page from scratch by calling its database.

# Request goes to origin server 
curl  --tlsv1.3 -s -o /dev/null -w "%{time_total}\n" -H "User-Agent: Chrome" https://www.transparentcdn.com/?p=random
0,596708

# Request is serve from CDN server
curl  --tlsv1.3 -s -o /dev/null -w "%{time_total}\n" -H "User-Agent: Chrome" https://www.transparentcdn.com/
0,167391

As shown in the example, there is quite a significant time improvement. In this case, it's 3.6 times faster to serve the content from the CDN.

Other benefits of a CDN

In addition to the above, a CDN has many other benefits, including:

• Optimization of resources on the origin platform. Because most traffic is cached and served from the CDN, the origin platform where the client hosts its web pages sees its traffic fall by 80-90%, reducing the number of necessary resources like servers, bandwidth, and even maintenance staff.

• Cost savings. The resource optimization generated by the CDN results in cost savings on infrastructure, meaning that the cost of the service more than pays for itself.

• Absorption of big spikes and traffic volumes. A CDN allows you to handle large volumes of traffic and spikes that would be very difficult to manage on the origin platform.

• Easy implementation. Implementing a CDN is as easy as making a simple change in the client’s DNS so that any website that wants to pass through the CDN no longer points to the origin web server and instead points to the CNAME provided by the CDN.

Transparent Rocks!

We created our CDN in 2011 with the idea of building the CDN we would have liked to have had as clients. That’s why our main asset is the people who work at Transparent Edge, and our main value is our proximity to end users.

A VPS (virtual private server) is a virtual partition of a physical server sold by a VPS provider. Each virtual server can run its own operating system and is allocated exclusive host resources. VPS clients have root access and can typically install any operating system they want.

A web service is a software service used to communicate between two or more networked devices. Specifically, it is a software application with a standardized way of integrating web-based applications. It uses technologies such as XML, SOAP, WSDL, and UDDI over HTTP or HTTPS protocols.

We want you to be as autonomous as possible on a day-to-day basis, but we know that sometimes you might need a hand. So, if you have any technical questions or problems—if even if you’re unhappy with the office coffee machine—don’t hesitate to write to our support team.

Plus, in honor of our name, we’re happy to share a list of email addresses that you can use at any time:

Updating content

When you work with a CDN, be aware that there is an element in front of your website which is caching all the content you publish. If you want to update an element on the page, once you have it how you want it, you must be sure to delete the cached content from the CDN cache to make way for the new content.

The process of deleting that content is known as invalidating, and there are several options for doing so.

Client IP

When you are behind our CDN, you won’t see the client IP address in the usual way. This is because Transparent Edge is making the requests to the origin servers on the client's behalf. But don't worry, all is not lost.

To deal with this situation, Transparent Edge has created extra HTTP headers that allow us to send customers the IP address of the real user who is doing the browsing. So, even though the server is behind the cache network, the customer can still take the appropriate actions based on the real IP address. We do this with X-Forwarded-For and/or True-Client-IP headers.

IPS/IDS Systems

If you have IPS/IDS systems on your origin platform, you need to be extremely careful. Even though these systems are intended to protect your platform, they can cause problems when working behind a CDN.

One of the many benefits of IPS systems is that they can detect when a particular IP address is accessing a resource illicitly.

As mentioned above, when you are behind a CDN, all the requests to your origin server will come from the CDN's IP addresses. So, the IPS may think that the CDN's IP addresses are making more requests than any one IP should make and restrict them as if it were an attack.

This is obviously a false positive that can be corrected, but it’s something to keep in mind.

Root domains

With Transparent Edge—like with many other CDNs—the most common way to start running the service is by making a simple DNS change so that, for instance, the www subdomain of your website will no longer be an A record but a CNAME record that we’ll give you when you sign up.

So far, so good. But if your website runs directly with the canonical domain—that is, without the www or any other domain (e.g.: https://mysite.com instead of htttps://www.mysite.com), you’re not done quite yet:

• If your domain doesn’t have any MX records added to it, in theory you’ll be able to use the CNAME of the canonical domain, although not all DNS providers support this option. We repeat: This is the easiest option, but it’s not available with all DNS providers.

• Another option would be to let us take care of the domain management within our DNS system.

Set-Cookies and pages with basic authentication

Web pages whose responses have the Set-Cookies or Authorization headers are cached in Transparent Edge by default.

Cache systems like Transparent Edge can provide countless benefits to your website, like reducing load times of pages, absorbing high traffic volumes, improving the security of portals, and sometimes even reducing infrastructure costs.

However, like everything in this world, this one also has its difficulties, although once you understand how a cache works and the flow of HTTP requests, it’s relatively straightforward. In this entry, we’ll explain how an HTTP request works internally, analyze request and response headers, and show you how they get interpreted by an HTTP cache.

The figure above shows the flow of a website request for an HTTP object from a conventional client to the web server that hosts the site www.transparentedge.eu (without passing through a cache). Not too complicated, right? Let’s take a deeper look.

After establishing the TCP connection with the server—generally over port 80—the client sends an HTTP GET method request for the “/” object (this “slash” object is the site’s homepage; if the client wanted a different object, instead of “/” you would see, for instance, “/categories” or “/image.png”).

The client sends the GET request with a set of headers, all of which are optional except the Host header. The Host header is used so that servers configured for multiple domains know which of their websites needs to be served to the client. Without this header, the server would understand that it had to serve the default website. As mentioned, the rest of the headers are optional, although modern browsers typically send a good deal of information in request headers. These often include the User-Agent header, which identifies the type of browser used for the request; the Cookie header, which contains information stored on the user's browser that is put to multiple uses by the website; and the Referer header, which tells the server the address of the page making the request.

In the response to this request, the web server sends the content itself along with another set of headers, some of which are rather important to the subject at hand.

This might appear to complicate things, but it's actually simpler than it seems. To help you understand it, we’ll follow the request through all its steps.

First—and this step is always the same—the client or web browser makes an HTTP request. But instead of going directly to the web server, in this case it's going to pass through a cache like Transparent Edge. This step is completely transparent to the web client, because it doesn’t actually know whether the request is going directly to a web server or to a cache. So: The request is received by the cache system and the cache checks whether or not the object being requested by the client is available in the cache. If it is, the object is returned without having to request it from the web server. If it isn’t, as is the case in our example, the cache will request the object from the web server, resending the exact same request it received from the client (step 2).

At this point, the web server receives the request, processes it, and sends the requested content to the cache along with the response headers (step 3).

The cache has just received the content from the web server and this is where the magic of caching occurs: the cache inspects the headers of the HTTP response and reads the Cache-Control header where the server tells it to store the object for 2592000 seconds (30 days). This means that during that time, every time the cache receives a request for that object it won’t have to get it from the web server and can instead serve it directly from the cache. This improves the loading speed of the pages and reduces the work of the web server.

At this point, the cache system adds another set of headers, like the Age header, which tells the client how many seconds the object has been stored in the cache, and the TP-Cache or TP2-Cache headers, which are exclusive to Transparent Edge and tell the browser whether the object has been served from the first cache (TP-Cache: HIT), from the second cache (TP2-Cache: HIT), or from no cache (TP-Cache: MISS and TP2-Cache: MISS) in which case the object had to be requested from the web server.

Finally, in the fourth step, the cache sends the content to the client, which interprets and displays it.

The CNAME will have the following structure:

<SERVICIO>.<ID_CLIENTE>.edge2befaster.net

We’re going to look at how to do the configuration using this CNAME as an example:

caching.c4.edge2befaster.net

Once you know your assigned CNAME, you just have to go to your DNS provider (normally it’s where you bought your domains) and change the record you want to pass through Transparent Edge.

www.tudominio.com	    A	    1.1.1.1

You’ll have to delete that record and create a new one that is a CNAME instead of an A record, pointing to caching.c4.edge2befaster.net. Such as:

www.tudominio.com    CNAME    caching.c4.edge2befaster.net 

This change does not happen automatically and how long it takes primarily depends on two things:

1. The time your DNS provider takes to apply the changes, which is usually immediate.

2. The DNS propagation time. According to the RFC, it can take up to 24 hours to see the change, but it generally only takes a few minutes. This delay is due to the DNS architecture itself and the caching times of each domain.

There are two methods for invalidating content: PURGE, which is a single invalidation that invalidates one particular object; and BAN, which is a recursive invalidation that can invalidate more than one object at a time.

Cache Key

A cache key is how the CDN saves an object to its cache. By default, the cache key is made up of:

[Host header] + [url] + [Query Stream]

From there, we can complicate the cache key as much as we wish, adding more elements to save more versions of the same object. Let’s look at an example:

https://www.transparentcdn.com/index.html?param=1

https://www.transparentcdn.com/index.html?param=2

For Transparent Edge—and in general for any other system of HTTP caches—these are distinct objects. Therefore, even if the first one is cached, it will download again to the origin when the second one is requested.

https://www.transparentcdn.com/index.html?param=1

And a Vary header like this:

Vary: User-Agent

We can make the CDN cache save as many objects as the number of user-agents requesting them.

Single or PURGE invalidations

This kind of invalidation lets you invalidate one particular object in the cache. To do so, you must be sure to enter the full URL with all the parameters included.

One type of PURGE invalidation is known as a SOFTPURGE, which is much less aggressive.

Recursive or BAN invalidations

BAN invalidations let you invalidate cache content recursively, by sending a blacklist and telling the cache to invalidate any object that matches it. For instance, we can tell it to invalidate https://www.transparentedge.eu/images/. This would invalidate any object that matches this URL, such as:

https://www.transparentedge.eu/images/image1.png or https://www.transparentedge.eu/images/2020/02/22/index.php.

By default, Transparent Edge geolocates all requests that pass through our systems by sending a header to the origin with the country code from which the request was made. This is the Geo_Country_Code header.

geo_country_code: ES

If the system was unable to locate the user's IP, it sends the Unknown string in the header.

Thanks to this feature, there are a great many things we can do based on the location of the end user, such as:

• Block/permit content from certain countries.

• Send requests to different origins based on the geographical location of the end user.

• Serve special content by country.

• Rewrite headers based on the country the request came from.

• Custom rules based on that header.

Cache headers are key to the correct functioning of a cache system in general, and of Transparent Edge in particular. Using them significantly increases the load speed of web pages, improving the user experience.

Transparent Edge uses several types of headers to know whether or not to store an object in its cache, but in this document, we're going to focus on the Cache-Control header.

At Transparent Edge, the Cache-Control header takes preference over all other cache headers—so if there are more than one, it’s the only one we’ll pay heed to.

The Cache-Control header is an improvement in HTTP/1.1 which simplifies the previous caching mechanisms in the HTTP/1.0 protocol. We use this header to indicate to intermediate caches and the browser cache whether or not an object should be stored and for how much time.

Like all HTTP headers, Cache-Control is a key-value pair, where the key is always the word Cache-Control. In terms of the server’s response, this value can be:

public

The Public header indicates to the cache that the object is public and therefore cacheable. It’s not typically found alone in the Cache-Control header.

private

Unlike Public, the Private header indicates that the content should not be cached because it is user-personalized content and should only be stored on the client's local device.

no-cache

The No-Cache header prevents an object from being cached in Transparent Edge. Even if the object is stored, it is never used.

no-store

This option prevents the cache from storing—and therefore caching—the object.

must-revalidate

This option forces the cache to go to the origin for a new copy of the object, telling it to disregard the rest of the cache headers and go get a new copy.

proxy-revalidate

This works just like Must-Revalidate but only affects proxies.

max-age

This header is used to indicate to Transparent Edge how many seconds we want the object to be stored in the cache and marked as valid. Once this time has passed, the object is marked as expired and the system is forced to go to the client’s origin servers for a new copy. This option affects both proxies and browser caches.

s-maxage

This is exactly the same as Max-Age, except it only affects the behavior of proxies and not browser caches. The two can be used in conjunction to create special behaviors, for example:

Cache-Control: max-age=0, s-maxage=3600

In this special case, the object will be stored on Transparent Edge for one hour (3600 s), but it won’t be stored in the browser.

The Age response header tells us how many seconds the object has been in the cache of the node serving the request.

curl -v -H "User-Agent: TCDN" https://www.transparentcdn.com/ > /dev/null
< HTTP/1.1 200 OK
< Server: nginx
< Date: Wed, 20 May 2020 15:11:57 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Link: <https://www.transparentcdn.com/wp-json/>; rel="https://api.w.org/"
< Link: </wp-includes/css/dist/block-library/style.min.css?ver=5.2.4>; rel=preload; as=style, </wp-content/plugins/contact-form-7/includes/css/styles.css?ver=5.1.4>; rel=preload; as=style, </wp-content/plugins/cookie-law-info/public/css/cookie-law-info-public.css?ver=1.8.1>; rel=preload; as=style, </wp-content/plugins/cookie-law-info/public/css/cookie-law-info-gdpr.css?ver=1.8.1>; rel=preload; as=style, </wp-content/plugins/revslider/public/assets/css/rs6.css?ver=6.1.1>; rel=preload; as=style, </wp-content/themes/cesis/style.css?ver=5.2.4>; rel=preload; as=style, </wp-content/themes/cesis_child_theme/style.css?ver=5.2.4>; rel=preload; as=style, </wp-content/themes/cesis/css/cesis_media_queries.css?ver=5.2.4>; rel=preload; as=style, </wp-content/themes/cesis/css/cesis_plugins.css?ver=5.2.4>; rel=preload; as=style, </wp-content/themes/cesis/includes/fonts/cesis_icons/cesis_icons.css?ver=5.2.4>; rel=preload; as=style, </wp-admin/admin-ajax.php?action=dynamic_css?ver=5.2.4>; rel=preload; as=style, </wp-content/plugins/js_composer/assets/css/vc_lte_ie9.min.css?ver=6.0.5>; rel=preload; as=style, </wp-content/plugins/js_composer/assets/css/js_composer.min.css?ver=6.0.5>; rel=preload; as=style, </wp-content/themes/cesis/admin/redux-extensions/extensions/dev_iconselect/dev_iconselect/include/fontawesome/css/font-awesome-social.css?ver=5.2.4>; rel=preload; as=style, </wp-includes/js/jquery/jquery.js?ver=1.12.4-wp>; rel=preload; as=script, </wp-includes/js/jquery/jquery-migrate.min.js?ver=1.4.1>; rel=preload; as=script, </wp-content/plugins/contact-form-7/includes/js/scripts.js?ver=5.1.4>; rel=preload; as=script, </wp-content/plugins/cookie-law-info/public/js/cookie-law-info-public.js?ver=1.8.1>; rel=preload; as=script, </wp-content/plugins/revslider/public/assets/js/revolution.tools.min.js?ver=6.0>; rel=preload; as=script, </wp-content/plugins/revslider/public/assets/js/rs6.min.js?ver=6.1.1>; rel=preload; as=script, </wp-content/themes/cesis/js/cesis_collapse.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/cesis_countup.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/cesis_easing.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/cesis_fittext.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/fitvids.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/fonticonpicker.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/lightgallery.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/owlcarousel.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/scrollmagic.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/cesis_transition.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/smartmenus.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/isotope.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/waypoints.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/cesis_custom.js?ver=5.2.4>; rel=preload; as=script
< TP-l2-Cache: HIT
< X-Device: desktop
< Age: 5622
< content-security-policy-report-only: default-src https: data: 'unsafe-inline' 'unsafe-eval'; report-uri https://api.transparentcdn.com/v1/csp/report/4/
< TP-Cache: HIT
< Vary: , Accept-Encoding
< strict-transport-security: max-age=31536000; includeSubDomains; preload

The Vary header can be very useful, but sometimes dangerous. It is used to tell caches (either the browser cache, a proxy, or a CDN like Transparent Edge) to save different versions of the same object depending on a given header. Let’s look at some examples of how to use it well and what not do to.

Bad use of the Vary header

HTTP/1.1 200 OK
Vary: Cookies
Cache-control: max-age=86400
Content-Type: text/html; charset=UTF-8
TSSecure: SecureLayer
client-id: 4
TP-l2-Cache: MISS
X-Device: desktop
Date: Mon, 19 Oct 2015 15:24:05 GMT
Age: 85783
Connection: keep-alive
TP-Cache: HIT

In the response headers in this example, we can see the Vary: Cookies header. This tells the caches to save a different version of the same object—like an image or a homepage—for each different cookie received. In other words, this type of request would have a very low hit ratio, possibly below 10%, rendering the cache system ineffective.

Another bad use example is the Vary: User-agent header, which would save a different version of the same object for every user-agent that visits the site. Be warned, there are quite a few user-agents out there!

Good use of the Vary header

HTTP/1.1 200 OK
Vary: Accept-Encoding
Cache-control: max-age=86400
Content-Type: text/html; charset=UTF-8
TSSecure: SecureLayer
client-id: 4
TP-l2-Cache: MISS
X-Device: desktop
Date: Mon, 19 Oct 2015 15:24:05 GMT
Age: 85783
Connection: keep-alive
TP-Cache: HIT

Here we are saving a different version of an object based on whether or not the object is compressed. This is done to maintain backward compatibility with old browsers and is the typical example of using this header well.

Another example is the Vary: X-Device header. When we use Vary this way, we tell Transparent Edge to save a different version of the object based on the X-Device value, which can be desktop, mobile, or tablet.

All requests that pass through Transparent Edge automatically get a set of headers added to them that we think can be useful for the origin. They are as follows:

True-Client-IP

Because CDNs function as reverse proxies, if you don’t make any changes, you’ll no longer see your users’ IP addresses in your origins (and therefore in your logs). Instead, you’ll see the IP addresses of Transparent Edge's servers. This is because the users establish a connection with our servers, so we are the ones making a request to their servers in the case of a MISS. This header is included to give you traceability of end users. Unlike the X-Forwarded-For header, this one sends the end user’s IP without any intermediate proxies.

geo_country_code and geo_region_code

For each request, we geolocate the users’ IP addresses using a specific geolocation database. Although it's possible to gather more information using VCL, we take the most common and useful data and include them in header paths available in both VCL and the client's origins, with data about the country's ISO code and the geographical region where the IP is located.

We update the databases weekly, but the accuracy of the region is limited by factors such as the providers’ CGNAT. The country code, however, is highly reliable.

X-Device

We know that managing user-agents can be a nightmare, which is why we standardize the User-Agent header of the original request and create an extra header with three possible values: mobile, tablet y desktop.

X-Forwarded-Proto

Despite the growing standardization of HTTPS certificates worldwide, there are still web services that use the HTTP protocol to communicate in plaintext. The X-Forwarded-Proto header—also reflected in logs—has a value of http or https to indicate whether the original request was in plaintext or ciphertext.

Transparent Edge can use the User-Agent header to determine the type of device that is connecting and categorize it as a desktop, mobile, or tablet.

To identify the device, Transparent Edge includes a header called X-Device in both the request to the origin and the response to the client. This header can have three values:

• desktop

• mobile

• tablet

Force device (feature available on request)

Even if the device is detected, it's possible to, for instance, force a mobile device to display a desktop version. We do this using the Force-Device cookie. If this cookie is present, it takes priority over X-Device.

As we explain in the document

Transparent Edge is made up of two cache layers.

We can optionally add a header in the Mid-Tier to all the requests that pass through the CDN to let us know whether the object was served from the cache or whether it was necessary to go to the next layer or the origin server to find it.

These headers are TP-Cache (in layer 1) and TP2-Cache (only in Mid-Tier). This header can have the value HIT or MISS depending on whether or not the object was served from the cache.

Let's look at some examples:

TP-Cache: HIT
TP2-Cache: MISS

In this case, the object was served from one of the layer 1 caches, without having to go to the Mid-Tier to find it.

TP-Cache: MISS
TP2-Cache: HIT

This is the opposite scenario: The object was not in layer 1 or was expired there, and when requesting it from the Mid-Tier that cache found a fresh version of the object which was served from that layer. Therefore, the request did not ultimately have to go to the client's origin servers.

TP-Cache: MISS
TP2-Cache: MISS

In this final case, a valid copy of the object was not found in the cache, either because it was not a cacheable object or because it was expired, so the request went directly to the client's origin servers.

curl -v -H "User-Agent: TCDN" https://www.transparentcdn.com/ > /dev/null
< HTTP/1.1 200 OK
< Server: nginx
< Date: Wed, 20 May 2020 15:11:57 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Link: <https://www.transparentcdn.com/wp-json/>; rel="https://api.w.org/"
< Link: </wp-includes/css/dist/block-library/style.min.css?ver=5.2.4>; rel=preload; as=style, </wp-content/plugins/contact-form-7/includes/css/styles.css?ver=5.1.4>; rel=preload; as=style, </wp-content/plugins/cookie-law-info/public/css/cookie-law-info-public.css?ver=1.8.1>; rel=preload; as=style, </wp-content/plugins/cookie-law-info/public/css/cookie-law-info-gdpr.css?ver=1.8.1>; rel=preload; as=style, </wp-content/plugins/revslider/public/assets/css/rs6.css?ver=6.1.1>; rel=preload; as=style, </wp-content/themes/cesis/style.css?ver=5.2.4>; rel=preload; as=style, </wp-content/themes/cesis_child_theme/style.css?ver=5.2.4>; rel=preload; as=style, </wp-content/themes/cesis/css/cesis_media_queries.css?ver=5.2.4>; rel=preload; as=style, </wp-content/themes/cesis/css/cesis_plugins.css?ver=5.2.4>; rel=preload; as=style, </wp-content/themes/cesis/includes/fonts/cesis_icons/cesis_icons.css?ver=5.2.4>; rel=preload; as=style, </wp-admin/admin-ajax.php?action=dynamic_css?ver=5.2.4>; rel=preload; as=style, </wp-content/plugins/js_composer/assets/css/vc_lte_ie9.min.css?ver=6.0.5>; rel=preload; as=style, </wp-content/plugins/js_composer/assets/css/js_composer.min.css?ver=6.0.5>; rel=preload; as=style, </wp-content/themes/cesis/admin/redux-extensions/extensions/dev_iconselect/dev_iconselect/include/fontawesome/css/font-awesome-social.css?ver=5.2.4>; rel=preload; as=style, </wp-includes/js/jquery/jquery.js?ver=1.12.4-wp>; rel=preload; as=script, </wp-includes/js/jquery/jquery-migrate.min.js?ver=1.4.1>; rel=preload; as=script, </wp-content/plugins/contact-form-7/includes/js/scripts.js?ver=5.1.4>; rel=preload; as=script, </wp-content/plugins/cookie-law-info/public/js/cookie-law-info-public.js?ver=1.8.1>; rel=preload; as=script, </wp-content/plugins/revslider/public/assets/js/revolution.tools.min.js?ver=6.0>; rel=preload; as=script, </wp-content/plugins/revslider/public/assets/js/rs6.min.js?ver=6.1.1>; rel=preload; as=script, </wp-content/themes/cesis/js/cesis_collapse.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/cesis_countup.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/cesis_easing.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/cesis_fittext.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/fitvids.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/fonticonpicker.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/lightgallery.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/owlcarousel.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/scrollmagic.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/cesis_transition.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/smartmenus.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/isotope.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/waypoints.js?ver=5.2.4>; rel=preload; as=script, </wp-content/themes/cesis/js/cesis_custom.js?ver=5.2.4>; rel=preload; as=script
< TP-l2-Cache: HIT
< X-Device: desktop
< Age: 5622
< content-security-policy-report-only: default-src https: data: 'unsafe-inline' 'unsafe-eval'; report-uri https://api.transparentcdn.com/v1/csp/report/4/
< TP-Cache: HIT
< Vary: , Accept-Encoding
< strict-transport-security: max-age=31536000; includeSubDomains; preload

The client’s IP address is masked by Transparent Edge’s cache network. This means that the client’s origin server is always going to receive connections from an IP address in our cache network. Plus, that cache network will vary over time, making it impossible to filter by IP address (level 3 OSI).

To do so, at Transparent Edge we create extra non-standard HTTP headers to be able to send our clients the IP addresses of the actual users who are doing the browsing. This lets clients take the appropriate actions with the addresses even though the server is behind the cache network. This is done using the X-Forwarded-For and/or True-Client-IP headers.

From there, it’s up to the client to capture the header and operate with it.

What's the difference between X-Forwarded-For and True-Client-IP?

X-Forwarded-For is a standard HTTP header where the software of various proxies adds the client’s IP address, including corporate systems. This means that if a request crosses several layers, several addressees will appear in the header separated by commas. As a result, clients will either have to “separate” the last IP address or analyze several of them.

True-Client-IP returns the last IP address before the request reaches the Transparent Edge servers. It corresponds to the first IP address of X-Forwarded-For and is therefore the actual address of the client that initiated the connection.

Just what we all love: Sending headers from the origin

To force an object to not be cached, you can configure the Cache-Control header with any of these values:

no-cache
no-store
max-age=0
private
must-revalidate

Although there are small differences in each one, they have the same effect in practice which is for the content not to be cached. If we had to choose one, we’d use no-cache.

Not caching or bypassing the cache of the CDN

The following covers the majority of use cases for not caching or bypassing the cache of the CDN.

Bypass or ignore the cache of the CDN

With this option we can ignore the cache and go directly to the origin to retrieve a fresh object always. Note that this doesn't prevent the object from entering in the cached after the backend response is executed, but it ensures that the client will never receive a cached response. Just call bypass_cache to ignore, skip or bypass the cache.

sub vcl_recv {    
    if (req.http.host == "www.transparent.com" && req.url ~ "^/admin") {
        call bypass_cache;
    }
} 

Don’t cache the object in the CDN by rewriting the origin headers

sub vcl_backend_response {    
    if ((bereq.http.host == "www.transparent.com") && (bereq.url ~ "/my-new-url")) {
            unset beresp.http.Cache-Control;
            set beresp.http.Cache-Control = "max-age=0";
            set beresp.ttl = 0s;
    }
} 

With this code, we rewrite the headers that come from the origin and add the amount of time we want the object stored in the cache. In our case, it is 0s—both for the internal TTL which will force the object to be stored in the Transparent Edge cache, and for the cache header to be sent to the browser (Cache-Control).

As part of our transparency policy, it’s important that the Transparent Edge nodes can be identified at all times, not just by our clients but by any person who wishes to know them.

That endpoint contains all the IP addresses that may connect to your origin/backend, it's extremely important that those IPs are allowed in the origin server(s) firewall, IDS, etc.

At the time of posting this entry (November 22, 2022), Transparent Edge has more than 50 PoP (Points of Presence) distributed worldwide to offer the best possible user experience. We are the only CDN with three PoP in Spain.

These are web server error codes, which are very different from other errors like 404 - Not found, which typically occurs when you request an object that doesn’t exist on the server.

Some of the most frequent error codes are:

• 500 - Internal Server Error

• 502 - Bad Gateway

• 503 - Service Unavailable

• 504 - Gateway Timeout

For technical reasons, CDNs mask all those status codes into a single error code. At Transparent Edge, we use the code 503 for any 5xx server error.

There can be many reasons for a 503 error from the CDN. They are categorized in the response headers and in the HTML code of the error, providing relevant information that can help us discern the error type. These headers begin with TCDN- and all of them end with a numerical value that lets us accurately identify the request. For instance:

TCDN-BENG-504:275330054.

List of codes

• TCDN-BENG-5xx - Backend Error No Grace

The object isn’t in the cache and the origin has responded with a 5xx error not categorized in any of the tags below. The number in the header is the exact error code returned by the origin. For instance: TCDN-BENG-504.

• TCDN-BENG-Service Unavailable - Backend Error No Grace (Network error)

The object isn’t in the cache and a network error ocurred while fetching it from the origin backend.

• TCDN-SBPR - Sick Backend POST/PUT Request

The request is not cacheable and caused an error at the origin.

• TCDN-SBNG - Sick Backend No Grace

The origin is marked as sick (its healthcheck is failing) and the object isn’t in the cache.

• TCDN-DNF - Domain Not Found

The domain was not found; it is not registered in the CDN.

• TCDN-NBD - No Backend Defined

The domain exists in the CDN but no backend has been assigned to it.

• TCDN-OENG - Origin Error No Grace

There was an origin error 5xx and we are keeping the original status code from origin without 503 status code masking due the X-Show-Origin-Errorsheader.

• TCDN-OK - No backend error found

The request was delivered successfully.

Layer 1

Layer 2 (Mid-Tier)

Transparent Edge's Mid-Tier is designed to act as a funnel and minimize the number of requests that reach our clients’ origin servers. This server layer is distributed across several data centers to ensure high availability, and it is ultimately in charge of talking with the origin web servers.

To better understand the benefits of this architecture, let’s look at an example:

Suppose we only had one layer of 10 cache servers, all of them talking directly with the origin servers. With a smooth flow of traffic, when an object expires it will do so more or less at the same time in all the caches. So each of the 10 servers would send a request to the origin server to refresh the object.

Total: 10 simultaneous requests to the origin.

Now suppose we add a second cache layer comprised of two servers. This layer will talk directly with the client's servers and with Layer 1. Layer 1 will still have 10 servers and will only talk with the second layer we just added (funnel).

Under the same circumstances of a smooth traffic flow, an object will expire on all the servers at the same time and the 10 servers will request the object from the second cache layer. This layer only will request the object from the origin twice (once per server) because it can serve the other eight requests without having to go get the object from the client’s origin servers. In this case, we are reducing the traffic at the origin by 80%.

Total: 2 simultaneous requests to the origin.

When required, Transparent Edge can do SSL terminations by caching requests as if they were in HTTP. In this case, the traffic is sent encrypted between the user and Transparent Edge. The certificate is then decrypted in our caches and all the traffic within the Transparent Edge platform is sent in HTTP. This lets us apply web caching technology to the SSL traffic. The traffic between Transparent Edge and the client's origin server can be sent in HTTP or HTTPS, at the client’s discretion.

By default, we use HTTP2 on tlsv1.2 and tlsv1.3.

Automatic management of SSL

At Transparent Edge, there are always several different ways of doing something. In this case, we give you two options for serving a secure website.

The second, and simpler, option is to leave the entire matter of certificates to us. We’ll take care of sending you valid certificates and renewing them, so you don’t have to do or worry about anything.

For this to happen, the domain does have to be pointing to Transparent Edge.

The hit ratio is one of Transparent Edge’s most important indicators. It tells us how effectively Transparent Edge is performing and the degree of optimization of a particular website.

A hit ratio under 80% needs to be reviewed. However, 80% means that of all the requests and bandwidth of a particular site, 80% are being served from Transparent Edge without going to the client’s origin server. So, only 20% of the requests are going to the web server.

In other words, we are saving 80% on infrastructure costs at the origin.

When there are connectivity problems between Transparent Edge’s servers and the client's origin servers—whether due to a service failure or any other problem recovering content from the origin—Transparent Edge will serve an expired version of the content. This will be done for up to a maximum of eight hours or until communication is reestablished between Transparent Edge and the client’s origin servers.

For Transparent Edge to be able to serve that expired content when there are problems, the objects served need to have a cache time (Cache-Control: max-age) of over 1 second. In other words, objects marked with non-cacheable headers (No-Store, No-Cache, Private, etc.) will not be served when there are problems, because they don't exist in the cache. So these requests will return an HTTP 503 error.

Refetching is a function through which, after content is invalidated via a PURGE, you force the object to be requested again from the content-invalidation agent running on the CDN nodes.

That way, when a real user request comes in, that object will already be in the cache and you won’t have to go get it from the origin.

Prefetching is a functionality that lets us fetch content before it reaches users. It can be very useful on occasion. Let’s look at two examples:

• Your website sees low traffic, but when a user arrives and requests an object, you still want it to be served by the CDN's cache.

• You’re going to launch your new website and you’re expecting a great influx of visitors, which translates into a high number of requests to the CDN. If the CDN is cold and doesn’t have any objects cached, when you go live a flood of requests to your origin servers could cause systems to collapse.

Transparent Edge makes its website logs available to customers. This can work in two different ways:

1. (PULL): The customer can download the logs from an FTP set up for that purpose.

2. (PUSH): Transparent Edge can send the logs every hour to an FTP that the customer makes available to us for that purpose.

Log format - Web Caching Service

203.0.113.5 - - [10/Aug/2024:06:20:13 +0000] "GET http://www.transparentedge.eu/wp-content/plugins/ninja-forms/assets/fonts/fontawesome-webfont.woff2 HTTP/2.0" 200 66624 "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36" hit "font/woff2" "L1" 1194 "82" "https://www.transparentedge.eu/wp-content/cache/wpo-minify/1724664512/assets/wpo-minify-footer-a97725b0.min.css" https ES "OK" "TCDN-OK:782763138" 1766

• Field 1: Client IP.

• Field 2: Remote logname. Always '-'.

• Field 3: Username from auth basic.

• Field 4: Date and time (UTC).

• Field 5: HTTP Method.

• Field 6: URL requested.

• Field 7: Protocol.

• Field 8: Status code.

• Field 9: Size of the object.

• Field 10: User-Agent.

• Field 11: Result of the request (HIT/MISS).

• Field 12: Content type.

• Field 13: Cache layer that served the request (L1/L2).

• Field 14: Response time of the request in microseconds.

• Field 15: Client ID.

• Field 16: Referer.

• Field 17: Real protocol (because we undo the HTTPS in a layer prior to the cache layer, this field is necessary to identify if the original request was made via HTTP o HTTPS).

• Field 18: Country code.

• Field 21: Remaining TTL of the object.

Format of WAF logs

47.62.117.136 - - [25/May/2020:15:03:22 +0000] "GET http://www.example.com/elt/ HTTP/1.0" 200 12423 "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36" "text/html" "waf" 1 "179"

• Field 1: Client IP.

• Field 2: Remote logname. Always '-'.

• Field 3: Username from auth basic.

• Field 4: Date and time + time difference.

• Field 5: Host header.

• Field 6: Request URL.

• Field 7: Protocol.

• Field 8: Status code.

• Field 9: Size of the object.

• Field 10: User-Agent.

• Field 11: Content type.

• Field 12: Layer that served the request (in this case WAF).

• Field 13: Response time of the request.

• Field 14: Client ID.

At Transparent Edge, by default, we use fast purging to instantaneously purge content. This system lets us invalidate content on all Transparent Edge nodes in under two seconds.

How do we implement fast purging?

Redirect to HTTPS

When your website runs with SSL, it’s typical to want everything that comes in unencrypted via HTTP to be sent to the secure version to make sure nobody is browsing your website insecurely. To do so, you just have to call redirect_https.

Redirects 301 and 302

It’s important to understand the implications of the two types of redirects. A 301 is a redirect that, in theory, isn’t going to change, so it gets cached in browsers. If it does eventually change, it’s very complicated to un-cache that resource.

A 302, meanwhile, is a temporary redirect for a resource, so it’s not cached in browsers or intermediate proxies.

At Transparent Edge, by default, we geolocate all the requests that pass through our systems by sending a header to the origin with the code for the country where the request was made. This header is Geo_Country_Code.

geo_country_code: ES

If the system is not able to locate the user’s IP address, it sends the Unknown string within the header.

This functionality gives us a range of possibilities for taking into account the end user’s location, such as:

• Blocking/allowing content from certain countries.

• Sending requests to a particular origin based on the end user’s geographic location.

• Serving special content by country.

• Rewriting headers based on the country requests come from.

• Establishing personalized rules based on the value of the header.

We understand static objects to be all objects requested from a server via HTTP or HTTPS protocol that don’t change after they are created. Examples of static objects include images, texts, compressed files (ZIP, TGZ, etc.), style sheets (CSS), JavaScript, XML, etc.

We understand dynamic content to be just the opposite: requests made from a client to a server via HTTP or HTTPS protocol that change with every user iteration. Examples of dynamic content include a bank transaction, a personalization in the HTML of a website, or an online shopping process.

At Transparent Edge, we can cache both static and dynamic content. However, the latter greatly depends on the type of website and how often it is updated.

Let’s take the example of an e-commerce site that has a private user area in the upper-right menu, where a welcome message appears. When you log into the site, you see a page adapted to your shopping preferences. What many e-commerce and similar sites with user personalization do is directly not cache in this area, setting a cache header of zero seconds or sending no-cache in the Cache-Control.

At Transparent Edge, it’s possible to cache all that content if the origin can use a cookie or another header to identify whether or not the user is logged in. So, we could save a cached version of the page for users who aren’t logged in (anonymous browsing) and a different version of the page for every one of the different users who are logged in.

Rewriting headers is very common and rather easy to do. The most typical cases are:

Rewriting the Host header

The typical use case:

sub vcl_recv{
  if ((req.http.host == "www.transparentcdn.com") && (bereq.url ~ "/blog")) {
    set http.host == "blog.transparentcdn.com"
    set req.backend_hint = c83_tcdn.backend();
  }
}

Rewriting the Cache-Control header

sub vcl_backend_response {
     if ((bereq.http.host == "www.transparentcdn.com") && (bereq.url ~ "/my-new-url")) {
            set beresp.http.Cache-Control = "max-age=0, s-maxage=10";
            set beresp.ttl = 10s;
    }
}

Deleting headers

Based on the previous example, we can erase the Cache-Control header that comes from the origin before forcing the cache time.

sub vcl_backend_response {    
    if ((bereq.http.host == "www.transparent.com") && (bereq.url ~ "/my-new-url")) {
            unset beresp.http.Cache-Control;
            set beresp.http.Cache-Control = "max-age=0, s-maxage=10";
            set beresp.ttl = 10s;
    }
}    

Transparent Edge can use the User-Agent header to determine the type of device that is connecting and categorize it as a desktop, mobile, or tablet. To identify the device, Transparent Edge includes a header called X-Device in both the request to the origin and the response to the client. This header can have three values:

• desktop

• mobile

• tablet

Force device

Even if the device is detected, it's possible to, for instance, force a mobile device to display a desktop version. We do this using the Force-Device cookie. If this cookie is present, it takes priority over X-Device.

On this page you will find more real-time information that is very valuable for your business. Unlike the historic, analytics retains data for the past 36 hours (to view older information, you can consult the historic section).

It can be filtered according to your needs, but the previous hour filter it is applied by default. The maximum period that can be applied for filtering is six hours.

The panel can be customized according to your needs. It displays the following options.

You will also find the requests and bandwidth information.

Hit ratio graphs are then displayed, which include all the cache efficiency information. The missed objects are displayed, along with the expired objects and stale objects. As a whole, depending on the settings, the entire response time of the requests can be displayed.

The following graphs display the response codes of all the requests received by the site and the geographical location from where these requests are sent.

The following graphics show every response code returned to the requests received and the geographical origin of this requests.

The following graphs display the protocol being used (HTTPS or HTTP) and the source of the requests in terms of devices.

Requests by country and the most requested URLs per site are found here.

The next graph displays all the purges performed by clients through the panel. Next to it is the table of all the contents of each site, how many requests it receives, and how much bandwidth it consumes.

All this is displayed in the status codes graph, and the referrer table displays the URLs from where the requests are sent.

The IP address table shows the IPs from where the requests are sent. The content type graph, on the other hand, displays information on the contents of each site.

The Transparent Edge Dashboard is the tool that allows users to control what's happening to their traffic in real-time and to know the consumptions of all the contracted services.

It can be run via API for the creation of custom dashboards integrated into the client infrastructure with all desired information, and is available in both Spanish and English.

On the main page, users can instantly view all the historical information about the service provided by Transparent Edge.

In the left-hand menu, users have direct access to the different sections that their permissions allow, such as user management, billing or the different services that Transparent provides for the client.

Invalidating (or purging) is as important as caching. Purging removes the object from the cache before it expires or is evicted.

Once an object has been purged, a subsequent request will fetch it from the source instead of from the cache.

Here, we'll explain how to invalidate using four methods:

• Simple invalidations (PURGES)​

• Soft invalidations (SOFTPURGES)​

• Recursive invalidations (BANS)​

• Simple + Warm Up​

There is another type of invalidation that leverages on tags attached to the objects and is explained here.

Remember that everything that can be done on our dashboard is available via API for automation.

To create an invalidation, log in to our dashboard and go to:

Invalidation -> Purge -> Purge URLs

A wizard will be displayed explaining the different invalidation methods available. You can click on "Advanced mode" to paste a list of URLs directly or complete them using the wizard.

Simple invalidations (PURGES)

This is the standard way of purging an object. A full URL is required, and you can invalidate multiple URLs in a single request, for example:

https://www.example.com/myobject.js

https://www.example.com/myobject.js?v=2.0

https://www.example.com/img/image.jpg

Protocol is required but it does not matter whether it is http or https.

This method immediately removes the object from the cache, and the subsequent request will fetch it from the source (your original backend).

Soft invalidations (SOFTPURGES)

This method purges by complete URL, like the PURGE method, but it has one notable difference: objects are not immediately purged from the cache, instead they are flagged as expired (or stale). The subsequent request will serve the cached object, and a background process will update the object in the cache from the source. If the update succeeds, the old expired object will be replaced.

This method is very useful if you want to protect yourself against backend failures. If your backend has issues and is unable to serve content and you PURGE an object, the CDN will return a 503 error. If you use SOFTPURGE instead of an error, it will return the cached yet expired object (provided that the object is actually in the cache). You decide.

Recursive invalidations (BANS)

This method uses a pattern to invalidate content which is similar to a regular expression.

For example, if you wanted to invalidate all the images in /content/img/, you would request a BAN invalidation with the following pattern:

https://www.example.com/content/img/

You still need to incorporate the protocol and domain.

Be very careful with BANs. A BAN at the root of your site: https://www.example.com/ invalidates the full content of the cache, and all subsequent requests will go directly to your backend.

We encourage you to use other available methods, including invalidation by tags.

Simple + Warm Up

This method behaves in the same way as the PURGE method, the difference is that after the object is invalidated from the cache a request is made to the same URL automatically to warm the cache with a fresh object.

What is invalidation by tags and how is it implemented?

A fundamental part of a website's proper functioning has to do with controlling cached objects and how and when to invalidate them. By using tag invalidation, we tag groups of objects so that we can quickly, efficiently, and selectively invalidate them. This avoids the need to devise complex scripts to construct the set of URLs to invalidate whenever the content is updated and we want to invalidate selectively.

At Transparent Edge, we use the Surrogate-Keys header to determine which tags are assigned to an object. When a miss occurs, which means a currently uncached object is requested, we go to the origin. For each object in the origin's response, we check for the existence of the Surrogate-Keys header and, if it exists, we assign its value as a tag to the object. If the value of the Surrogate-Keys header consists of several words separated by spaces, we assign all of them to the object, which means they can be invalidated using any of them.

Example:

# request
GET /portada.html HTTP/1.1
Host: www.example.com

# response
HTTP/1.1 200 OK
Surrogate-Keys: main statics1
Content-Type: text/html
...

The object will be labeled with "main" and "static1". Therefore, if we make an invalidation request for any of those two tags, we will invalidate that object and all those that include that tag. This allows us to group related objects that need to be invalidated at the same time, regardless of what URL they have.

Each object can have multiple associated tags, if a request is made to invalidate by tag, all the objects that share that tag will be invalidated at once.

Relationship between tags and objects

The power and control provided by invalidating by tags is that it allows for a many-to-many relationship between tags and objects. The origin server's response can associate multiple tags with an object, and those tags can be shared by other objects, creating relationships between them.

An example of this would be the following two requests with their backend response:

GET /shop/ HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK Content-Type: text/html
Content-Length: 875
Surrogate-Key: shop main-shop

GET /shop/product/24656-tshirt HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 4123
Surrogate-Key: shop product-tshirt

In the example above, we have two objects (/shop and /shop/product/24656-tshirt) with three tags (shop, main-shop, and product-tshirt). Two of them (main-shop and product-tshirt) are assigned to a single object, and a third (shop) is assigned to both.

This enables us to create associations between objects at will and invalidate them in a completely selective way.

Generating and assigning tags

This can be done in two ways:

• From the origin server (recommended).

• From the CDN using VCL code.

From the origin server

It must be implemented directly in the application or in the webserver that serves the content from the origin.

An example if the origin server is using Nginx would be:

  location ~* ^/content/.*\.(css|js|png|gif)$ {
      add_header Surrogate-Keys "statics content";

This will tag all the objects with the extension css, js, png or gif under the path /content/ with the tags statics and content.

From VCL configuration

We need to incorporate the tags into the subroutine vcl_backend_response.

sub vcl_backend_response {
    if (bereq.url ~ "\.(jpg|jpeg|png|gif)($|\?)"){  
       set beresp.http.Surrogate-Keys = "images " + beresp.http.Surrogate-Keys;
    }
}

The above example will add the tag images to all the resources with the extension jpg, jpeg, png or gif.

The space after the tag plus the addition of the header Surrogate-Keys:

"images " + beresp.http.Surrogate-Keys;

is recommended. if the origin sends additional tags in the Surrogate-Keys header they will not work without it.​

Purge/invalidate objects using tags

Purging via panel (dashboard)

Invalidation -> Purge -> Purge TAGs

Enter the tags that you want to purge and click "Purge TAGs".

Purging via API

You'll need to make an authenticated POST request to /v1/companies/<company_id>/tag_invalidate/

The body of the request must have the key "tags", for example:

// tags.json
{
    "tags": [
        "main",
        "rss"
    ]
}

$ curl -kv --request POST --data @tags.json \
 -H "Authorization: Bearer <API_TOKEN>" \
 -H "Content-Type: application/json" \
 "https://api.transparentcdn.com/v1/companies/512/tag_invalidate/"

The prefetching cache function enables you to request content to be loaded to all edge node caches automatically, and it "warms up" the cache with the requested URLs.

Our dashboard allows you to prefetch for a given resource, i.e., you cache the content on your nodes so that it is immediately available to your clients without having to make the request to the source.

From our dashboard

Log in to our dashboard and go to:

Prefetching cache -> New prefetch

Enter the list of URLs you want to prefetch and click on "Prefetch".

Using our API

Create a POST request to

/v1/companies/{company_id}/prefetch/

The body must contain a key named "urls", for example:

{
  "urls": [
    "https://www.example.com/image.jpg",
    "https://www.example.com/style.css"
  ]
}

The log sending feature is included in any service package. It just needs to be activated and set up for it to start.

Format and frequency

In batch mode, logs are extracted, compressed and sent every hour. On average, there is one compressed log file for each edge node belonging to our delivery platform, provided requests have been processed on these and related with any of the sites involved.

Every compressed log file has the following name mask::

<YYYYMMDDHH>-<CID>-<COUNTRY CODE>-<HASH>.log.gz

Thereby:

1. The first field corresponds to the send date (YYYYMMDDHH).

2. The second is the unique client /company ID.

3. The next one represents the country code associated to the geographical location of the edge node meeting those requests.

4. Last but not least, a hash code is included which identifies the edge node itself. This field is used internally for traceability and debugging purposes.

For instance: 2023022010-4-spain-c7658c0dd514f6523f7a98ddd0dbb448.log.gz

Log shipping to a FTP / sFTP server

This choice allows the log to be sent to an arbitrary FTP / sFTP server.

To set it up properly, simply specify the correct protocol and fill in the gaps with the remaining parameters required. Once this choice is activated and its parameters validated, sending will begin within the next hour.

Log shipping to an Amazon S3 bucket compatible

This choice allows the log sending to a compatible Amazon S3 bucket.

In order to properly set it up, an access and secret key credential pair must be provided that must also be associated with a policy allowing, at least, file uploading into the bucket that is to be used.

Bucket field allows two name masks:

• <ENDPOINT URL>/<BUCKET NAME>

• <BUCKET NAME> (just in case of Amazon S3 bucket)

<ENDPOINT URL> corresponds to the URL hosting the S3 service. In the scenario where the bucket is hosted in Amazon S3, it is possible to use just the <BUCKET NAME> as the sole parameter.

Anywise, if it must also be included, for instance, to point to a specific geographical region, the bucket name must be removed from the domain itself: https://tcdn-testing.s3.us-east-1.amazonaws.com/tcdn-testing would become https://s3.us-east-1.amazonaws.com/tcdn-testing. If this is not done, the bucket name will be included at the beginning of the remote path.

Sorting out compressed log files by date and time

When log sending is being configured, path field, which represents the remote path where compressed log files will be stored, allows for a set of special date--related masks:

• %Y, year

• %m, month

• %d, day

• %H, hour

For instance, if the value of path field is /tcdn-logs/%Y/%m/%d and today is February 20, 2023, when the process is executed, the compressed log files will be remotely stored in the path /tcdn-logs/2023/02/20.

Log sending by streaming

Configuring the Backend

The backend must first be defined. +This is the external server (host) where the website that we are configuring on the auto-provisioning platform is currently hosted. At CDN level, the backend is your origin.

The following data are required for the correct configuration of the backend:

Name:

You must provide a descriptive name for the backend.

This name will be used in the different VCL (Varnish Configuration Language) configurations indicated later. It is preceded by the prefix c[company_id]_, where [company_id] is your unique user identifier in the Transparent Edge Services auto-provisioning platform.

For example, a backend name could be: cNNN_example.

Source IP

This is the public IP of the external server where the website is currently hosted.

If you have a domain name for that server, it can also be used instead of its IP. The only restriction is that the domain name for the origin cannot be the same as the one used later in the website configuration.

For example, an origin domain name could be: source.example.com.

SSL Encryption

This checkbox is ticked to indicate that communications with the backend must be encrypted.

Port

This complements the previously established origin IP or domain name.

It is the port through which the connection to the origin will be established.

Generally, if the connection is unencrypted, the HTTP (Hypertext Transfer Protocol) will be used, the standard port of which is 80. However, if an encrypted connection is required, HTTPS (HTTP Secure) will be required, the standard port of which is 443.

Health check

A health check must be configured to monitor the backend status. The following variables are required for this purpose:

Host

Header of the host associated with the health check.

This is an optional field, so it can be left blank or it can contain any value accepted by the origin server.

For example, a valid associated host header could be: health_check.example.com.

Verification URL

This is the URL that the health check will verify.

For example, a valid verification URL could be: /verify.

Status code

Expected status code for the health check verification.

For example, a status code for the health check verification could be 200; this is the most common (status code: OK), although there is no restriction on this. For instance, a response code 301 (status code: MOVED PERMANENTLY) is also possible.

Domain Registration

After completing the data related with the backend configuration, the website to be associated with that backend must be registered. This is done in the next step by clicking on "Add site".

Let's see this with an example domain: www.example.com.

To ensure the indicated website belongs to us, we will be asked to place a file named tcdn.txt in the root directory of the website with a specific content (the verification code), so that a request of the type http://www.example.es/tcdn.txt returns the text previously provided.

Alternatively, we can create a TXT record with the name "_tcdn_challenge" and the verification code content.

VCLs

Once the information regarding both the backend and the domain (site) has been completed in the configuration wizard, an excerpt with the generated VCL (Varnish Configuration Language) configuration will be displayed.

VCL (Varnish Configuration Language) is simply a script language used to configure and add logic to the Varnish cache.

For example, the backend and site values previously referred to would result in the following VCL configuration:

sub vcl_recv {
    if (req.http.host == "www.example.es") {
        set req.backend_hint = cNNN_ejemplo.backend();
    }
}

As can be seen, this is just an initial configuration that links the backend cNNN_example with the site www.example.es. This allows the CDN to retrieve non-cached resources (MISS).

You can end the wizard here and complete the VCL configuration later.

Summary

Finally, the configuration wizard will inform you of the modifications you will need to make in the DNS settings to point to the domain previously indicated in the CNAME (Canonical NAME) record of Transparent Edge.

For example, our assigned CNAME record would be: caching.cNNN.edge2befaster.net.

You can find this CNAME record in both the activation email and at the top of the Auto-provisioning panel.

This page contains all the historical information of the service provided by Transparent Edge.

The last six months are displayed by default but you can filter by the last year, month or week, or by specific website.

Depending on the filter chosen, all the information panels are recalculated. All the graphs and information provided can also be downloaded in PNG, SVG or CSV format by clicking on the top left of each panel.

If you need to share information already filtered, you can copy the link and send it to another user to view the same information.

The first and second panels offer more detailed information on requests per second and bandwidth, itemized by site and time period. The panel normally displays information for today. It can also be filtered so that they are displayed together, showing the total for all sites, or separately, showing all graphs stacked to count the total requests per second and bandwidth of all sites linked to Transparent Edge.

The third and fourth panels show the information from the first and second panels (request per second and bandwidth) but displayed as a pie chart, giving more graphic visualization of this information.

After these graphs, the monthly bandwidth consumption information and requests received are displayed, providing our customers with information on their consumption. With this data, it is possible to make forecasts of future consumption for the current month, which is valuable information for all company departments.

If you have more services contracted with Transparent Edge, you can view their history by changing the option at the top of the panel. There, you will be able to see all the consumption of each service over a period of time.

Consumption Alerts

At the top of the page, you will find the "Limit Alerts" button, which allows you to create a new consumption alert for your service. This alert is designed to notify you when your service's consumption exceeds a predefined threshold.

You can customize the alert to trigger specific actions, such as:

• Delivering a Slack notification.

• Forwarding the alert data in JSON format to a specified URL.

This feature ensures you stay informed and can take timely action to manage your service consumption effectively.

In this section, you'll be able to view/add or delete the sites managed by our CDN.

Provisioning -> Sites

Adding a new site

The entire verification process is explained in detail when you click on "ADD SITE".

What is the lock icon next to my sites?

I can't verify my site / I have to add a lot of sites at once

In this section, you'll be able to view/add/edit or delete backend configurations.

Provisioning -> Backends

A backend (or origin server) is a server identified by an IP address or DNS name. This is where your CDN will fetch your content.

Backend configuration

The following options are required when creating or editing a backend.

In this section, we will explain how to manage the configuration logic that applies to your sites in the CDN.

Our CDN uses a modified version of the Varnish Configuration Language (VCL), a powerful language that will enable you to customize your site behavior.

Visualizing the current state

To view the configuration deployment currently active, navigate to:

Provisioning -> VCL Configs

A table will be displayed with the history of all configurations.

The current and active configuration is the one marked with a green tick under the "Status" header. You can see when that configuration took effect under "Deployment date".

You can perform the following actions on any of the configurations:

• View - Opens a read-only view of the configuration, where you can check the code and compare with other configurations.

• Duplicate - Opens an editor to deploy a new configuration prefilled with the code of this particular configuration.

• Back to production - A quick way to deploy an older configuration again, it's a "rollback" button.

Deploying a new configuration

To deploy a new configuration, click on the "ADD VCL CONFIG" button or, if you want to edit over an older configuration, use the "Duplicate" button instead.

An editor will be displayed where you can edit the VCL code or you can copy it to your favorite editor and paste it later.

The editor embeds some autocompletion that can be activated using the CTRL key.

When you're done editing the configuration, click on "Save". The configuration will be checked for syntax errors and, if any are present, an error will be shown. For example, here we tried to use req.http in the vcl_backend_response subroutine which only accepts bereq.http and beresp.http:

Otherwise, if the code is correct. the deployment will be queued and a clock will be displayed in the status of that configuration. Deployments usually take between 2 and 7 minutes to fully propagate.

The following sections explain how to manage the provisioning platform offered by Transparent Edge.

How to use a Network ACL in Auto Provisioning

First, take note of the name of the Network ACL, for example acl_c4_mylist.

Now, create a new VCL configuration cloning the last one.

Modify and adapt one of the below examples for your use case.

Deny list example

# Deny list example
sub vcl_recv {
    if (req.http.host == "www.mydomain.com") { # any required condition to trigger the ACL check
        if (aclplus.match(client.ip, network_acl.get("acl_c4_mydenylist", "none"))) {
            # Any action is allowed here, for this example we block the request
            call deny_request;
        }
    }
}

Use the following conditional to combine multiple deny lists together:

if (aclplus.match(client.ip, network_acl.get("acl_c4_deny1", "none"))
        || aclplus.match(client.ip, network_acl.get("acl_c4_deny2", "none"))
   ) {
    # Block the request if the IP is present in any ACL
    call deny_request;
}

Allow list example

Here we just inverted the condition to transform this into an allow list (only the IPs present in the ACL will be accepted)

# Allow list example (we just inverted the condition, notice the '!')
sub vcl_recv {
    if (req.http.host == "www.mydomain.com") { # any required condition to trigger the ACL check
        if (!aclplus.match(client.ip, network_acl.get("acl_c4_myallowlist", "none"))) {
            # Any action is allowed here, for this example we block the request (if the IP doesn't match the ACL)
            call deny_request;
        }
    }
}

Use the following conditional to combine multiple allow lists together:

if (!aclplus.match(client.ip, network_acl.get("acl_c4_allow1", "none"))
        && !aclplus.match(client.ip, network_acl.get("acl_c4_allow2", "none"))
   ) {
    # Block the request if the IP is not present in any of the ACLs
    call deny_request;
}