Default Inherited Configuration

The Introduction describes how a channel configuration for a channel named example is stored at the following location:

/hst:hst:
  /hst:configurations:
    /example:
      jcr:primaryType: hst:configuration
copy

Configuration inheritance explains how the example configuration can inherit from and merge with another configuration.

/hst:hst:
  /hst:configurations:
    /example:
      jcr:primaryType: hst:configuration
      hst:inheritsfrom: [../common]
    /common:
      jcr:primaryType: hst:configuration
copy

Every hst:configuration node also implicitly inherits from a default configuration:

/hst:hst:
  /hst:configurations:
    /hst:default:
copy

The hst:default configuration is always inherited and does not require explicit inclusion through the hst:inheritsfrom property.

Purpose of hst:default

The hst:default node is the only fixed, non-project-specific configuration node under hst:hst/hst:configurations. Both the delivery tier (HST) and plugins use this node to bootstrap their configuration.

By default, the delivery tier adds sitemap items to hst:default that match requests for static webapp resources, webfiles, authentication requests, and repository binaries:

/hst:hst:
  /hst:configurations:
    /hst:default:
      /hst:sitemap:
        /_any_.css:
        /_any_.CSS:
        /_any_.gif:
        /_any_.GIF:
        /_any_.ico:
        /_any_.ICO:
        /_any_.jpeg:
        /_any_.JPEG:
        /_any_.jpg:
        /_any_.JPG:
        /_any_.js:
        /_any_.JS:
        /_any_.pdf:
        /_any_.PDF:
        /_any_.png:
        /_any_.PNG:
        /_any_.svg:
        /_any_.SVG:
        /_any_.jsp:
        /_any_.JSP:
        /webfiles:
          /_default_:
            /_any_:
        login:
          /_any_:
        /binaries:
          /_any_:
copy

In this context, \_any\_ represents the ** matcher, and \_default\_ represents the * matcher.

For example, the Sitemap Plugin adds a sitemap.xml sitemap item to hst:default/hst:sitemap, making /sitemap.xml available in every channel.

Plugins or library features may also add component catalog items to hst:default, making them available across all channels.

The Static Webapp Files Matchers

The static webapp files matchers include nodes such as \_any\_.css, \_any\_.CSS, \_any\_.gif, up to \_any\_.JSP. Each of these nodes has the property hst:containerresource = true:

/hst:hst/hst:configurations/hst:default/hst:sitemap:
  /_any_.css:
    hst:containerresource: true
copy

Each HTTP request, including those for static webapp resources, is matched against a sitemap item. For example, a request to /css/style.css matches the \_any\_.css sitemap item. The HST then processes the request using the ContainerResourcePipeline. The final step in this pipeline, the containerResourceDispatchingValve, forwards the request to the servlet responsible for serving static webapp files.

You can extend the ContainerResourcePipeline with additional logic, such as authentication checks.

Nested sitemap structures are supported. For example, you can serve some CSS files only over HTTPS by nesting sitemap items accordingly.

The default matchers cover the most common static file extensions. You can add additional extensions to hst:default as needed.

A sitemap item with hst:containerresource = true (a container resource) can only be configured in the hst:default sitemap, not in other sitemaps. When generating a delivery tier link that matches a container resource sitemap item, the URL is relative to the web application (for example, /site) rather than the current channel (such as /site/fr/). By default, container resource sitemap items are scheme agnostic, so they work over both HTTP and HTTPS. To restrict a matcher to a specific scheme, set hst:schemeagnostic to false.

The Webfiles Matcher

The webfiles matcher supports Web Files. The configuration should look like this:

/hst:hst/hst:configurations/hst:default/hst:sitemap:
  /webfiles:
    hst:containerresource: true
    hst:namedpipeline: WebFilePipeline
    hst:refId: WEB-FILES-ID 
    /_default_:
      /_any_:
        hst:parameternames: version
        hst:parametervalues: ${1}
        hst:relativecontentpath: ${2}
copy

All webfiles URLs are treated as container resources. These URLs are relative to the web application, not to the matched channel. The webfiles sitemap item must include hst:refId = WEB-FILES-ID for web files to function. The \_default\_ matcher matches the timestamp in the web files URL, and the \_any\_ matcher matches the web file location in the repository.

The Login Matcher

The login matcher handles all delivery tier authentication requests:

/hst:hst/hst:configurations/hst:default/hst:sitemap:
  /login:
    hst:containerresource: true
    hst:namedpipeline: PlainFilterChainInvokingPipeline
    hst:scheme: https 
      /_any_:
copy

The Binaries Matcher

The binaries matcher serves binaries from the repository, including assets, gallery and document-embedded binaries. The default configuration is:

/hst:hst/hst:configurations/hst:default/hst:sitemap:
  /binaries:
    hst:containerresource: true
    hst:refId: BINARIES-PIPELINE-ID
      /_any_:
copy

Since the binaries matcher is a container resource, the same binary used in different channels on the same host (for example, http://www.example.org and http://www.example.org/fr) is accessed using the same URL. The binaries matcher delegates requests to the binaries servlet via the containerResourceDispatchingValve. In the CMS Experience manager, when previewing a channel, the binary preview is also served through this mechanism.