Network Profile

Architecture

The AEM Delivery services are set up as origins behind Content Delivery Network (CDN) infrastructure for production and are accessed by authors, stakeholders and developers directly from their browsers. In some cases the CDN infrastructure for production sites is hosted and managed by AEM customers directly (we call this BYO CDN) or it is managed by Adobe via a Cloud Service CDN (eg. BYO DNS).

The network profile below is relevant both for the interactions of end-users directly with their browsers (or other clients) but also for setup and communication from your CDN.

Delivery Services

DNS Scheme

We use a DNS scheme that identifies each origin with the following pattern. https://<ref>--<site>--<org>.aem.page (for preview) and https://<ref>--<site>--<org>.aem.live (for live content). <ref>, <site> and <org> commonly identify GitHub repositories and references (branches or tags). Special characters in references, orgs and repositories are replaced by a single -. The maximum length of a domain name label is 63 characters, which limits the length of the <ref>--<site>--<org> the combination.

The DNS records for aem.page and aem.live are delivered with a short 10-minute time to live (TTL), so that we can switch between delivery stacks. This happens automatically.

HTTP and TLS versions

The AEM Delivery endpoints support HTTP/1.1 and HTTP/2 (H2) and TLS 1.2. HTTPS (via TLS) is enforced. All .page and .live subdomains additionally set HTTP Strict Transport Security (HSTS) headers, so that downgrades to HTTP are prohibited.

HTTP Headers

Many HTTP headers can be configured by the project or are dependent on the payload, but there are some headers that are handled out of the box.

Cache-Control

The client-facing cache-control headers are set automatically by default to reflect production tested, continuously evolving, best practices based on resource types, response code and origin type. We recommend passing them on to the client "as is" through a customer's CDN.

Some resources that are immutable have very long max-age and others that tend to change more frequently have shorter max-age. On preview (.page) origins max-age is set very short, to avoid the explicit need for authors, developers and stakeholders to clear their browser cache when making changes.

We don't have any data that suggests that changing the cache-header values on a per customer basis provides improved experiences to visitors of the sites and we do have data that shows adverse effects from changes, but we appreciate that this is a contract between the browser and a customer's CDN and understand that this is out of scope for AEM to fully control.

It is important to note that these values apply only to the cache-control headers sent to the client, and are not related to cache management in the CDN, which is using push invalidation.

Cache-Control Header Values on `.aem.page`

Responses for	Header Value
`200` - Code (`.js`, `.css`, `.svg`, etc.)	`max-age=60, must-revalidate`
`200` - Content (`text/html`, `application/json`)	`max-age=60, must-revalidate`
`200` - Media (images, videos, etc.)	`max-age=2592000, must-revalidate`
`301` - Moved Permanently	`max-age=60, must-revalidate`
`304` - Code	`max-age=60, must-revalidate`
`304` - Content	`max-age=60, must-revalidate`
`404` - Code	`max-age=60, must-revalidate`
`404` - Content	`max-age=60, must-revalidate`
`5xx`	`max-age=60, must-revalidate`
`3xx`, `4xx` and `5xx` - Media	`max-age=3600, must-revalidate`

Cache-Control Header Values on `.aem.live`

Responses for	Header Value
`200` - Code (`.js`, `.css`, `.svg`, etc.)	`max-age=7200, must-revalidate`
`200` - Content (`text/html`, `application/json`)	`max-age=7200, must-revalidate`
`200` - Media (images, videos, etc.)	`max-age=2592000, must-revalidate`
`301` - Moved Permanently	`max-age=7200, must-revalidate`
`304` - Code	`max-age=7200, must-revalidate`
`304` - Content	`max-age=7200, must-revalidate`
`404` - Code	`max-age=7200, must-revalidate`
`404` - Content	`max-age=7200, must-revalidate`
`5xx` - Code and Content	`max-age=7200, must-revalidate`
`3xx`, `4xx` and `5xx` - Media	`max-age=3600, must-revalidate`

Vary

The vary header is set to Accept-Encoding,X-Forwarded-Host

X-Robots-Tag

The x-robots-tag header is automatically set to noindex, nofollow on any .live and .page origin to avoid indexing. This header is removed by the CDN tier for production only.

CDN Specific Headers

To manage the cache consistency with your CDN in an optimal way and support precise push invalidation there are custom headers set for each supported CDN that control the CDNs caching behavior and cache keys. The terminology and headers as well as the available features and semantics vary greatly between vendors.
These headers are only added for requests coming from a CDN and are consumed by the CDN and are not surfaced to the browser or other clients.

URL Space

The available URL space on the .page and .live origins is limited to a combination of upper and lowercase basic latin letters (A-Z and a-z), numbers (0-9), dash (-), underscore (_), period (.) and forward slash (/). Certain combinations of . and/or / in direct succession are also not valid.

If you need to service a broader URL space we recommend rewriting URLs on your CDN tier.

Access to the available URL Space

Developers and Authors have access to the full URL space via resources coming from GitHub, Folder names or redirect sources coming from the redirects spreadsheet.

Access to a more limited URL Space

File names in content sources (documents and spreadsheets in Sharepoint or Google Drive) are automatically rewritten to a more narrow character set including only lowercase basic latin letters (a-z), numbers (0-9) and dash(-) with the corresponding extension appended.

Admin Service (API)

The admin service endpoint available on admin.hlx.page (see API Spec here) is built to be accessed via a broad range of HTTP clients including browsers, command line tools as well as common HTTP clients.

It supports HTTP/1.1 and HTTP/2 (H2) with TLS 1.2. HTTPS (via TLS) is enforced.