Configure your CDN for Confluence Data Center

If your site is not publicly accessible, you'll need to make sure that your CDN can reach it, but only to access and cache static assets.  The way you do this depends on your particular load balancer and web application firewall. Refer to the documentation for your load balancer and firewall for detailed guidance. 

Add an internet-facing load balancer

Add an internet-facing load balancer to your setup. This is in addition to your primary load balancer. Your CDN is the only entity that will interact with this load balancer. We recommend you:

• Enable HTTPS - the traffic from this load balancer will be sent over the public internet and should be encrypted.
• Enable HTTP/1.1 - currently, the caching proxies and CDNs do not handle HTTP/2 well (or at all) on the way to the origin.
• For AWS deployments, you would set up an internet-facing application load balancer.

Update your firewall rules for the internet-facing load balancer

Unlike your primary load balancer, this internet-facing load balancer must be locked down to ensure that your CDN can only pull data it is allowed to cache. When configuring your firewall rules we recommend:

1. The configuration should only allow requests for paths that start with "/s/".  If your application is deployed with a context path (for example yoursite.com/wiki or yoursite.com/jira) you will need to include it in the path. All other requests must be blocked. 
2. You can also choose to limit the allowed HTTP methods to GET, HEAD, OPTIONS.

For AWS deployments, you will configure a Web Access Control List (WebACL) in the Web Application Firewall attached to your application load balancer. The condition to use is a "string match condition"  applied to "URI". 

To check that your setup is secure, perform the following manual tests:

1. A GET on https://internet-facing-proxy/  should return "403 FORBIDDEN".
2. A GET on https://internet-facing-proxy/s  should return "403 FORBIDDEN".
3. A GET on https://internet-facing-proxy/s/  should return "404 NOT FOUND".
4. A GET on https://internet-facing-proxy/s/.  should return "403 FORBIDDEN".
5. A GET on https://internet-facing-proxy/s/../s/  should return "404 NOT FOUND".

You'll need an account with a CDN provider. You're responsible for all costs associated with your CDN. We only support serving static assets from a CDN at this time. This means page content, attached files, and personally identifiable information, including things like user avatars, won't be cached by your CDN.

We've prepared a CloudFormation template that you can use to configure Amazon CloudFront with minimal effort. You can find all our AWS deployment resources in this repository https://bitbucket.org/atlassian/atlassian-aws-deployment/src/master/templates/cdn/. 

If you choose not to use our template, define the following in your CDN configuration.  This example is based on AWS CloudFront. 

Using the default should be fine for most of the other settings. 

You will need to adapt this information for your particular CDN provider. You should refer to the documentation for your CDN for details, as we've found that terminology differs between CDNs.

You can also interact with the CDN feature using the following REST endpoint: <base-url>/rest/static-asset-caching/configuration

• GET - returns the current CDN status, and URL.
• DELETE - deletes the existing configuration and reverts to the default state (CDN disabled, no URL). This is useful if you can't access the UI because of a caching problem.

• PUT - sets the CDN URL and status to the values passed in the body of the request as follows: 
   

  {
    “enabled”: true, 
    “url”: “https://yourcdnurl.com”
  }

Here are some common problems that you may encounter. 

• We only accept HTTPS CDN URLs 
  This is particularly important if you're using Azure CDN, as Azure CDN will mirror the same protocol as the originating request, which means your Data Center application will need to be provisioned with HTTPS. 

• Data Center application UI is inaccessible or not functional
  Although unlikely, a misconfiguration of your CDN or a CDN service outage may mean your application's UI is not accessible. If this happens, you will need to disable the CDN feature using the REST API, as follows.  

  curl -v -u <admin username>:<admin password> -X DELETE http://<your-base-url>/rest/static-asset-caching/configuration

  This example uses Curl, but you can use any language. Don't forget to replace the username, password, and base URL placeholders with your own details.  

• HTTP/2 disabled
  Your load balancer, firewall, or reverse proxy should allow HTTP/2 traffic. Using HTTP/2 will provide the best performance for your end users. See HTTP/2 health check fails in Data Center when configuring CDN for more information. 
• User-installed apps may not be compatible
  This warning is displayed when we detect that a Marketplace or other user-installed app is using a deprecated method, which may result in assets being cached incorrectly. See User-installed apps health check fails in Data Center when configuring CDN for more information on what to do if you see this warning. 

Frequently asked questions

Can I control what static assets are cached? 

No, the application controls this. All requests for static assets are routed to the CDN. Requests for non-static assets are routed directly to your product. 

Is personally identifiable information cached? 

User created content, usernames, mentions, avatars etc are not static assets, so are not cached. Your CDN should also be configured to pull content from your product with cookies stripped to make sure it operates without user context. 

Is dynamic content such as batch.js cached? 

Although dynamically generated, batch.js is considered static content, so is cached.