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

First and foremost: We're always standing by to help with whatever you may need. Feel free to contact us if you have any questions or even if you want us to do the initial configuration for you.

About Transparent Edge

If you’re reading this, it's quite possible that you already know us and that you even know exactly how a CDN works. However, before you begin, we encourage you to have a look through our documentation to familiarize yourself with all the possibilities offered by Transparent Edge. This would be a good place to start.

Sign up

Well, we can see you’ve made the decision. Still, we’d like you to know that it's never too late to turn back. You can cancel your service—much to our regret—by sending a simple .

But let’s not cancel before we’ve even gotten started. To create a Transparent Edge account, just go to our page. We explain everything .

Your first configuration

We try to make things easy for you and we like simple things. That’s why we've developed a to help you create your first Transparent Edge configuration.

Remember: We love listening to you and improving our service is our number one priority. So, if you see something you don’t like or that seems confusing, or that you think can be done better or more simply, we encourage you to write us an .

We’d be more than happy to help you.

So now what?

Congratulations, your website is functioning through Transparent Edge, but that’s just the beginning. Transparent Edge is based on software, opening up a world of possibilities when it comes to configuring the CDN. In our documentation portal, you’ll find the most common use cases and we explain how to implement them in our guides and tutorials section.

If you'd like to go even further, you can consult our manual, which will give you a deep understanding of what can be done with Varnish and Transparent Edge.

Here you’ll find all the documentation about using—and enjoying!—Transparent Edge. If you already know what you’re looking for, you ​can quickly access the reference. If you just got here, you’ll most likely want to start at the beginning:

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

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.

You can consult our complete API here.

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

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.

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.

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.

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.

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.

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.

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.

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.

TLS acceleration, formerly known as SSL acceleration, is a method of offloading processor-intensive tasks, like those needed to establish and maintain a TLS session and the initial key exchange.

Most TLS (Transport Layer Security) accelerators use dedicated processing cards or custom chips (ASICs and RISC).

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.

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.

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.

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.

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.

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 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.

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 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.

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 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.

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).

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.

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.

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.

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.

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.

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

Sign up

The process of signing up on Transparent Edge’s self-service platform begins by clicking the “Sign up” button in the top right corner of the . You will be redirected to a form where you have to complete two steps to create .

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.

You can also go into the system on our, where you can open a ticket or talk to us through our chat.

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

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

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.

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.

To find out how to do a prefetch, click this.

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.

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.

To find out more about the different invalidation methods, click

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

At Transparent Edge, we give you the option to limit the number of requests per second that enter your website. Click this to get more details on how it works and how to activate it.

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.

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?

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 is why we publish an endpointin our API with all our public IP addresses: .

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.

The same IPs can also be retrieved in plain format:

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.

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:

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).

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.

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:

• System virtual machines: They allow several operating systems to coexist on a single computer, strongly isolated from each other. The software layer that runs this virtualization is called a virtual machine monitor or hypervisor and, broadly speaking, it can run on the host’s bare hardware or on an operating system.

• 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.

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 following sections explain how to manage the provisioning platform offered by Transparent Edge.

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.

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?

It’s quite simple. All Transparent Edge nodes are subscribed to a fanout queue in an internal Rabbit MQ cluster. When it receives a content invalidation message from our API, the message is immediately consumed by an agent which runs on all our CDN nodes. The agent locally invalidates the requested content at that node.

If you want to find out more about how to invalidate content, click this link.

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.

You can do a refetch via API or from our dashboard, as explained in this link.

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.

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.

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.

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.

You can see the hit ratio on Transparent Edge’s client portal.

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.

To learn more about how to improve your hit ratio, have a look at this entry.

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:

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.

Because we are based on Varnish Enterprise software, Transparent Edge offers great flexibility when it comes to changing your website’s default behavior.

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

Deleting headers

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

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 first is for you to purchase your certificates from your trusted provider, and once you have them you can upload them to our platform or send us a so we can do it for you.

To upload certificates to the platform, go to our, select Provisioning from the left side menu, and then click on Certificates.

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.

It’s easy: in the Provisioning section of the, click on the Sites tab and then on the padlock icon for the website you want to protect with SSL.

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

Depending on the value of this header, Transparent Edge saves a version of each object for that device, making it possible to serve different content for each type of device under the same URL.

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.

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.

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:

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.

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.

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

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!

Smooth Streaming is a technology designed by Microsoft for its IIS Media Services product. This product enables the adaptive streaming of media to clients over HTTP.

When a is not able to process a request or simply isn’t available, your web browser receives a 5xx error response code—or in other words a code between 500 and 599.

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

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.

Just what we all love: Sending headers from the origin

At Transparent Edge we want our customers to have as much autonomy as they can. That's why we always encourage a CDN configuration that's as simple as possible and for cache headers to be sent from the origin servers whenever possible. This contains information on how to do it.

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

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.

Transparent Edge has two cache layers that are optional for our clients. The goal is to improve the and reduce the number of unnecessary requests to their origin servers. Plus, this type of architecture also protects against floods of traffic from, for instance, a recursive invalidation of a highly trafficked website.

Layer 1

Layer 1 is comprised of distributed servers, which are what initially attend to end-user requests. They act as SSL terminations and cache servers, serving nearly 95% of Transparent Edge.

These Layer 1 servers can be configured to be the origin of all the Layer 2 servers. That way, when an object needs to be refreshed, the Layer 2 servers send the request directly to the Layer 1 servers.

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)​

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.

We use the for this functionality, which can detect the country with an accuracy of 99.8%.

We can send other data provided by this database to the origin in the form of an HTTP header—the city, for instance—but bear in mind that the database can only detect cities with an accuracy of around 75% for Spain. You can check the accuracy data by country​

The value of the Geo_Country_Code header is the country code from the standard.​

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:

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

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.

X-Remote-Port

The same as the header True-Client-IP , this header is included to give you traceability of the port used by the end users as received by Transparent Edge`s servers.

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 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.

The RFC 2616, section 10 lists all the status codes supported by HTTP 1.1, but we are going to highlight the most relevant ones here.

Successful response

200 OK

The request was successful and the server returns a 200 status code to let the client know.

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:

408 Timeout

This is a complicated error. It means that the connection has been closed due to exceeding the wait time. If the error occurs on the client server, it will become a 503 in Transparent Edge. Under normal conditions, it’s often due to a communication problem: either an internal firewall, an internal server error, or a firewall/proxy between Transparent Edge and the client. Any “connection close” or “closing connection” message in the client’s server logs could mean a 408. Historically, we’ve had problems with Apache modules that cause this error, like the mpm_itk ().

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.

Transparent Edge protects you against all 5XX errors by showing you the latest cached version. You can get more information .

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.

The first and easiest option is to go to the Invalidations section of our portal following an update, click the Purge URL button, and enter the URL you wish to invalidate.

Another option is to use the API to integrate the invalidation process into the publication system. This way, your system will automatically detect when you change content and launch an invalidation through our .

If you are using,, or, we have plugins available that are specifically geared toward integrating the CMS with Transparent Edge so you don’t have to worry about it.

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.

We explain it in detail.

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.

At Transparent Edge we publish our ranges through our API. If you have these types of systems, we recommend including all the Transparent Edge IP addresses on a whitelist within the IPS.

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.

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.

This service is not enabled by default. If you’d like to enable it, follow the instructions here.

Log format - Web Caching Service

• 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 19: Multi-purpose field. If is active and performs any action, it's shown here.

• Field 20:

• Field 21: Remaining TTL of the object.

Format of WAF logs

• Field 1: Client IP.

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

• Field 3: Username from auth basic.

• Field 4: Date and time + time difference.

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.

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.

• Increased website security. The distributed nature of a CDN makes it possible to hide the origin servers from the final user, improving security. Transparent Edge also has additional security services like the.

Transparent Rocks!

Transparent Edge is the first and only Spanish content delivery network, with infrastructure in over 30 countries. Based on software, it’s the only CDN in the world to offer this Varnish mode with its full potential. Plus, we are a Varnish, giving our product an additional level of guarantee.

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.

The goal of this site is not to sell, but to make our clients’ lives easier. So, if you’re reading this, you already know who we are and you’re probably familiar with what makes us great. In fact, you might already be a client. In any case, on our you’ll find everything you need to know about Transparent Edge. And you can always send an email to the .

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:

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:

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.

We can use the header to modify the behavior and save more versions of the same object. For instance, with an object like this:

And a Vary header like this:

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.

To do an invalidation from our, just follow this.

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.

To do an invalidation from our, just follow this.

After you sign up for Transparent Edge, you’ll receive a welcome email. It will include a CNAME to complete the configuration.

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

This is the CNAME to point your domains at. You can also always find it in the Provisioning tab of our dashboard.

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.

Before we continue, we’d just like to mention that this way of working, using a CNAME, is only valid for subdomains like www.yourdomain.com or blog.yourdomain.com, never to point directly at yourdomain.com without a subdomain. This limitation is imposed by the and, although there are exceptions, many DNS servers simply don’t allow it.

Typically, you’ll want it to be the subdomain www.yourdomain.com. In this case, once you’re in your DNS provider, you’ll have to find the www record, which most likely points to an IP address with an record. Something like this:

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:

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.

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.

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

Provisioning -> Sites

Adding a new site

Adding a new site requires a verification of ownership of the domain being added, which is a security measure. If you have any doubts or need assistance, don't hesitate to contact our support .

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

What is the lock icon next to my sites?

This is our legacy method to obtain certificates, please refer to .

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

If you have any problems adding new sites, please contact our support. We can add sites in bulk and/or bypass the verification if there are any issues: .

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.

The log shipping feature is included in all service plans. It only needs to be activated and configured to start working.

Format and frequency

In batch mode, logs are collected, compressed, and sent every hour. Typically, one compressed log file is generated for each edge node in our delivery platform, as long as that node has processed requests for any associated site.

Each compressed log file follows this naming pattern:

Where:

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.

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.

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:

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:

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:

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.

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:

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)

Login into our and go to:

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:

With , you can do it like this:

Our dashboard provides two configuration methods. The first one, Easy Setup, is a simple rule engine that allows you to configure the system without dealing with VCL code. The second option gives you the ability to write your VCL code, enabling a more detailed customization of the system’s behavior.

Easy Setup

The Easy Setup is based on 'if-then' conditional logic. When the conditions of a defined rule are met, a specific action is applied. This system allows you to configure key actions on your sites in a simple and agile way with just a couple of clicks.

To create a new rule, we must select the site where our configuration will be implemented.Once selected, click the 'Add Rule' button, which will open a modal displaying the rule templates grouped by category.

In 'Cache & Performance' we can find:

• Bypass cache: Select the pages where requests skip the cache and go straight to the origin server.

• Cache time for CDN: Specify the TTL for the request.

• No cache: Disable caching for requests.

In Headers & Response we can see:

• Add header to the response: Add a custom header to the HTTP response before it is sent to the user.

• Header rewrite: Rewrite any response header before inserting in the cache.

• Unset header: Unset an origin header.

In Routing & Redirects are:

• Assing backend: Assign each site to its corresponding backend for precise and controlled routing.

• Permanent redirect (301): Set up a permanent redirect for your website.

• Temporary redirect (302): Set up a temporary redirect for your website.

• Redirect: Redirects users to another page.

In Security & Access Control we have:

• Request blocking: Block the selected request with an error code.

• Add exception to the WAF: A configuration that allows the WAF to bypass specific rules, preventing the blocking of allowed requests or behaviors.

• Rate limit: a mechanism that restricts the number of requests a client can make to a server within a given time period.

With the template already selected, we will choose whether the rule will apply to all inbound requests or, alternatively, if we want to define it for a custom filter rule. In the latter case, we must fill in the required values. Once everything is completed, we save, and our new rule will be implemented.

From the rules table, we can edit, delete, and deactivate the rules that have already been created.

Write your VCL code

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

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.

After activating our user account, you will be able to access the Transparent Edge panel through the URL using your username (registered email) and password defined during the registration process.

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:

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

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:

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.

We can use the header to modify the behavior and save more versions of the same object, as previously mentioned. For instance, with an object like this:

And a Vary header like this:

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.

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.

Backend Analytics

If you have advanced analytics enabled, you can find here a comprehensive set of statistics about the relationship between the CDN and your backend.

As with the other Transparent Edge panels, you can narrow your search by dates (and times) and, of course, filter while browsing the information or before viewing it.

Likewise, you can customize the widgets according to your needs, adding more or replacing the less frequently used ones with others that are more useful for your business. You can arrange the widgets according to your preferences: click and drag!

Response times

All this information makes it possible to detect issues related to bottlenecks and potential latencies in the content delivery chain, as it provides specific data on processing times at various stages of the CDN’s handling in relation to your backend:

1. Time Start

   • It is the moment when the CDN node begins processing the request.

   • It marks the starting point for measuring all subsequent times. Ideally, it tends to zero.

2. Response Time

1. Time Fetch

   • It refers to the time the CDN node takes to retrieve the content from the backend. This covers the period from when the request is sent until the complete response begins to be received.

   • It is a component within the Response Time, closely tied to the time the backend takes to process and respond to the request.

2. Time Beresp (backend response)

1. Time Error

   • This time relates to error handling. It may represent the interval during which an error in communication is detected and managed (for example, when the connection to the backend fails or another error occurs during processing).

   • Although it is not part of the “ideal” flow of a successful request, it is crucial for diagnosing bottlenecks or failures in the process. It differs from the previous times because it is activated in exceptional situations and helps isolate issues in communication or processing.

Vary headers

The HTTP header Vary indicates which header fields should be considered variable when a file is requested from the cache, and it helps servers determine how to match the headers of future requests to decide whether a cached response can be used instead of requesting a new one from the origin server. This header is useful for delivering content optimized for different devices or user agents, ensuring that users access the correct version of a web page for their device. However, if the Vary header is not configured correctly, it can reduce the benefits of the caching system and lead to excessive resource usage.

X-vary-tcdn is a header that Transparent Edge includes by default in Vary (hidden) and is used to create cache variants without needing to manipulate the standard Vary header.

With this information, you will be able to compare and track the behavior of these headers.

Information concerning the Backend

These two widgets refer directly to the backend. They provide information on requests to the origins, whether from instances that listen and serve or from virtual hosts.

Cache Control

Here we can visually observe how many requests (and their consumed bandwidth) belong to the different cache-setting parameters, including non-cached items.

ASN & Referer

From which network (ASN) has your traffic originated, and with what volume of requests and bandwidth? Would you like to know how many requests and how much bandwidth a request with a specific referer has consumed?

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:

In case of doubts, please reference our .

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.

 sub vcl_recv {  
     if (req.http.host == "www.transparentcdn.com") {
         call redirect_https;
     }
}

Redirects 301 and 302

Redirects can be performed by calling the function `redirect_request`, see .

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.