Serve Gallery Images, Assets, Web Files, and Static Webapp Files from a CDN

Introduction

Goal

Configure repository gallery items, assets, web files and static webapp files be served through a Content Delivery Network (CDN).

Background

When serving many binaries like gallery items and assets, webfiles, or static webapp files, or when you have large binaries which consume too much bandwidth, or when you want to reduce latency for serving binaries, you might want to choose to serve them from a Content Delivery Network (CDN). 

Serving files from a CDN is supported out of the box by Bloomreach Experience Manager, and per hst:virtualhost you can configure which CDN host you'd like to use. It's possible to change it on-the-fly in a running production environment.

Configure a CDN Host

On any hst:virtualhost node below /hst:hst/hst:hosts in the repository, you can add a new String property :

hst:cdnhost

The property, if configured, is inherited by child hst:virtualhost nodes, unless configured explicitly on a child node. To prevent a child node from inheriting the configured CDN host, add hst:cdnhost property and keep the value empty.

The supported CDN host format is:

//{cdnhost}

For example, suppose you want binaries to be served from cdn.example.org, then you need to configure:

hst:cdnhost: //cdn.example.org

other formats like //cdn.acct.example.org or //cdn.acct.example.org:8080 are also allowed. As of version 12.6.1, scheme prefixes such as http or https are supported although not recommended.

Example: For Production Hosts, Serve the Files from a CDN

/hst:hosts:
  /dev-env:
    jcr:primaryType: hst:virtualhostgroup
    /localhost:
      jcr:primaryType: hst:virtualhost
  /acct-env:
    jcr:primaryType: hst:virtualhostgroup
    /com:
      jcr:primaryType: hst:virtualhost
      /example:
        jcr:primaryType: hst:virtualhost
        /acct:
          jcr:primaryType: hst:virtualhost
      /example2:
        jcr:primaryType: hst:virtualhost
        /acct:
          jcr:primaryType: hst:virtualhost
  /prod-env:
    jcr:primaryType: hst:virtualhostgroup
    /com:
      jcr:primaryType: hst:virtualhost
      hst:cdnhost: //cdn.example.com
      /example:
        jcr:primaryType: hst:virtualhost
        /www:
          jcr:primaryType: hst:virtualhost
      /example2:
        jcr:primaryType: hst:virtualhost
        /www:
          jcr:primaryType: hst:virtualhost

In the above example, gallery items, assets, web files, and static webapp resources for domain http://www.example.com and http://www.example2.com will be loaded from http://cdn.example.com.

Technical : Why Should a CDN Start With // 

From RFC3986 chapter 5.4.1 you can read:

Within a representation with a well defined base URI of

http://a/b/c/d;p?q

a relative reference is transformed to its target URI as follows.

RFC 3986                   URI Generic Syntax               January 2005
5.4.1.  Normal Examples

      "g:h"           =  "g:h"
      "g"             =  "http://a/b/c/g"
      "./g"           =  "http://a/b/c/g"
      "g/"            =  "http://a/b/c/g/"
      "/g"            =  "http://a/g"
      "//g"           =  "http://g"
      "?y"            =  "http://a/b/c/d;p?y"
      "g?y"           =  "http://a/b/c/g?y"
      "#s"            =  "http://a/b/c/d;p?q#s"
      "g#s"           =  "http://a/b/c/g#s"
      "g?y#s"         =  "http://a/b/c/g?y#s"
      ";x"            =  "http://a/b/c/;x"
      "g;x"           =  "http://a/b/c/g;x"
      "g;x?y#s"       =  "http://a/b/c/g;x?y#s"
      ""              =  "http://a/b/c/d;p?q"
      "."             =  "http://a/b/c/"
      "./"            =  "http://a/b/c/"
      ".."            =  "http://a/b/"
      "../"           =  "http://a/b/"
      "../g"          =  "http://a/b/g"
      "../.."         =  "http://a/"
      "../../"        =  "http://a/"
      "../../g"       =  "http://a/g"

Example 6 is the relevant one: 

//g  =  http://g

The advantage with // is that it follows the scheme ( http or https) of the request that created the HTML in which references to binary files are added that need to be loaded from a CDN. This way, in the above example, when accessing http://www.example.org, all files are served from http://cdn.example.org and when accessing https://www.example.org, all files are served from https://cdn.example.org.