Home / Compiled Sites Delivery

Compiled Sites Delivery

Site Delivery

All Oracle Content Management sites use the same general page delivery flow. There is not a separate delivery flow for compiled sites. Rather, static page delivery is an extension to the standard delivery mechanism. The delivery flow is as follows:

Delivery Flowchart.

First, a determination is made if there is a compiled, “static” file corresponding to the incoming site URL. If there is a static file, then that static file is delivered. If there’s no static file, then the delivery algorithm continues to evaluate the possible “dynamic” responses.

When determining if a static file exists for a given URL, locale aliases and locale fallbacks are also accommodated. For example, consider a locale fallback that proceeds from “fr-FR” to “fr” and an incoming site-relative URL path matches “/fr-FR/products.html”. In this case the “/fr-FR/” segment is replaced with “/fr/” before determining if a compiled, “static” file exists.

Other Static File URL Matching Conditions

Along with direct URL-to-static-file matching behavior, several specific situations are also accommodated, including:

  1. Locale Fallbacks—If present, replace the locale fallback path segment with the corresponding fallback locale before doing path matching.

  2. Home Page—If the URL path matches the site prefix alone without the file name, then use the home page file name for matching purposes.

  3. Default Documents—If the URL path ends with a slash character, then append “index.html” as the default document for matching purposes.

  4. Detail Pages—If the URL path matches one of the site’s detail page path prefixes, then return the compiled detail page.

Static Delivery Cache Responses for Public Sites

The HTTP cache response headers served for statically delivered files can be specified at the service or site level. In order to set the service-level default response headers, the service administrator navigates to the System > Sites settings, and updates the Static Site Caching Response Headers value. (The administrator can also click the Show defaults button to reset the value to the defaults.)

Response Headers Administration.

Similarly, to set the caching response headers at the site-level, the site manager goes to Site Properties > Static Delivery, and updates the Caching Response Headers value.

Response Headers Site Settings.

Only one set of response headers will be used, either from the service level or from the site level. (The system will not combine the two sets.) If the site doesn’t have a set of cache headers specified, then the service settings will be used. If neither site-level nor service-level settings are defined, then the following built-in default values will be used:

Cache-Control: max-age=300
Edge-Control: !no-store,max-age=1800,downstream-ttl=1800

About Cache Response Headers

Oracle Content Management only honors the following HTTP response header names in the response header settings:

Other values present in the response header settings are silently ignored during static file delivery.

Default Header Values

The Cache-Control response header is a standard HTTP header. The max-age directive instructs downstream caches (like CDNs, proxies, and browsers) to cache the resource for the given number of seconds. The value of 300 advises caches to store the response for 5 minutes (300 seconds) before considering it stale.

The Edge-Cache response header is a custom HTTP response header honored by certain CDNs, including Akamai.

Static Delivery Cache Responses for Secure Sites

Cache response headers served with secure sites don’t use the settings above. Instead, the following response headers are used:

Cache-Control: no-store
Pragma: no-cache

This helps prevent caching sensitive information in intermediate or browser caches. There’s no mechanism to override these values at the Oracle Content Management servers (the origin).

Static Site Delivery and Akamai Caching

Static site pages delivered from Oracle Content Management are delivered with certain HTTP response headers that direct how caches should behave. Notably, public sites are delivered with Cache-Control max-age values that improve site performance by caching responses in intermediate caches like CDNs and proxies. Subsequent requests for the same resource are served from cache. Due to the potentially sensitive nature of its pages, secure site resources are served with response headers that prevent caching.

Consider the case where a static site page is delivered with 30 minute caching directives. This implies that Akamai or other CDNs will cache and serve the page for that length of time without requesting a fresh copy from the Oracle Content Management origin, even if the page on the origin has changed. The content will be delivered by the CDN for the specified freshness lifetime. This further impacts how quickly site changes can reach viewers. In this scenario, changes may not reach end users for up to 30 minutes.

Site managers should weigh the benefits of specifying long cache durations for overall site performance against the need to deliver changes quickly. Business objectives may also impact this calculation, as might the maturity and change characteristics of the site.

Cache Flushing

Flushing CDN caches is another mechanism of ensuring that browsers and end users are served the freshest copy of site pages. This is particularly beneficial for requests from new end users. There are a few caveats to consider with this solution, though.

First, flushing the CDN cache may not flush browser and proxy caches beyond the CDN. If the browser itself has a resource cached for, say, one hour, then it may fetch that page from its own local cache for that time period before ever requesting that URL from the network again. For that timeframe the browser does not “see” any page updates, no matter if the CDN cache is flushed and updated with the freshest material. One solution for this is to cache at the browser for a short amount of time and longer in the CDN backed up by cache flushing. However, this may have performance considerations since browsers will have to fetch from the network (to the CDN) more frequently.

Also, note that CDN cache flushing signals are not sent from Oracle Content Management. Cache invalidation mechanisms would need to be developed by custom code and procedures.

Finally, note that the Purge button found in the System > General administration page affects the default delivery domain for the Oracle Content Management service <service>-<tenant>.ocecdn.oraclecloud.com. It does not purge site vanity domains or friendly management domains.

CDN Purge button.

Locale Fallbacks

Locale fallbacks allow site developers to support designated locales even if they don’t have unique translations of their own. For example, a site can support an “en-US” locale by substituting “en” page responses for “en-US” requests. This feature may be beneficial for closely related or similar locales.

During site compilation, only pages for the target fallback locales are compiled. In the preceding example, only the “en” pages would be compiled. The “en-US” pages would not be compiled. Browser requests for “en-US” pages would be fulfilled with the corresponding “en” equivalents, though.

This feature has the added advantage of avoiding the compilation expense of processing the fallback locales. Depending on the nature and size of the site, this can be significant.