Serving Gallery items, Assets, Webfiles and static webapp files from a CDN

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 very easy to achieve with the CMS 10, and  per  hst:virtualhost you can configure which CDN host you'd like to use. It is also possible to change it in a running production environment. 

Howto

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

hst:cdnhost

The property if configured is inherited by child virtualhost nodes, unless configured explicitly on a child node. To remove cdn host on a child node, you have to 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 : serve for production hosts the files from a cdn

+ hst:hosts
  + dev-env               [hst:virtualhostgroup]
    + localhost           [hst:virtualhost]
  + acct-env              [hst:virtualhostgroup]
    + com                 [hst:virtualhost]
      + example           [hst:virtualhost]
         + acct           [hst:virtualhost]
      + example2          [hst:virtualhost]
         + acct           [hst:virtualhost]
  + prod-env              [hst:virtualhostgroup]
    + com                 [hst:virtualhost]
      - hst:cdnhost = //cdn.example.com
      + example           [hst:virtualhost]
         + www            [hst:virtualhost]
      + example2          [hst:virtualhost]
         + www            [hst:virtualhost]

in the above example, gallery items, assets, webfiles 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://cnd.example.org and when accessing https://www.example.org, or files are served from https://cdn.example.org.