Mount Matching

A Mount defines the mapping between a URL prefix and a (sub)site in Bloomreach Content. Each Mount directly under a virtual host must be named hst:root, which corresponds to the root path /. The hst:root mount matches all URLs by default.

When the root mount contains a child node with a name that matches the next segment of the URL path, that child mount is selected. A path segment is the part of a URL between two slashes. Mounts can be nested, forming a tree structure. The request handler always matches the deepest mount that corresponds to the URL, and uses that mount for further request processing.

Example: Basic Mount Configuration

The following configuration defines mounts for different locales under the localhost virtual host:

/hst:hst:
  jcr:primaryType:hst:hst
  /hst:hosts:
    jcr:primaryType:hst:virtualhosts
    /localhost:
      jcr:primaryType:hst:virtualhost
      /hst:root:
        jcr:primaryType:hst:mount
        /de:
          jcr:primaryType:hst:mount
        /fr:
          jcr:primaryType:hst:mount
        /nl:
          jcr:primaryType:hst:mount

With this configuration and an empty context path, the following URLs resolve to these mounts:

1. http://localhost:8080/home         --> hst:root
2. http://localhost:8080/news/2011   --> hst:root
3. http://localhost:8080/fr          --> fr
4. http://localhost:8080/fr/news     --> fr
5. http://localhost:8080/de          --> de

Example: Nested Mounts

Because mounts can be nested, you can define additional sub-mounts. For example:

/hst:hst:
  jcr:primaryType:hst:hst
  /hst:hosts:
    jcr:primaryType:hst:virtualhosts
    /localhost:
      jcr:primaryType:hst:virtualhost
      /hst:root:
        jcr:primaryType:hst:mount
        /de:
          jcr:primaryType:hst:mount
        /fr:
          jcr:primaryType:hst:mount
          /sub1:
            jcr:primaryType:hst:mount
          /sub2:
            jcr:primaryType:hst:mount
        /nl:
          jcr:primaryType:hst:mount

In this example, the French mount (fr) has two additional sub-mounts. The following URLs resolve as follows:

1. http://localhost:8080/fr           --> fr
2. http://localhost:8080/fr/news      --> fr
3. http://localhost:8080/fr/sub1      --> fr/sub1
4. http://localhost:8080/fr/sub2/news --> fr/sub2

Mount Configuration Properties

Mount nodes support both mandatory and optional properties. A mount inherits properties from its parent mount. The root mount inherits from its parent virtual host. You only need to specify properties on a mount if they differ from the parent configuration.

The most important property is hst:mountpoint, which specifies the absolute JCR path to the hst:site node containing the content and configuration for the mount. Other key properties are described in the table below.

Property name	Example	Description
`hst:mountpoint`	`/hst:hst/hst:sites/example`	Absolute path to the `hst:site` node for this mount.
`hst:homepage`	`home`	Sitemap item path or refId for the home page when the URL matches the mount exactly (e.g., `/`). The HST Linking Component first resolves by refId, then by path. For example, if the French site uses `hst:homepage = "home"` and its sitemap contains an item with `hst:refId = "home"` (such as `accueil`), the link will resolve to that item.
`hst:locale`	`en_US`	Locale for this mount. This value is set on the `HttpServletRequest`, enabling I18n resource bundles without additional configuration.
`hst:pagenotfound`	`404page`	Sitemap item path or refId for the page-not-found link. The HST Linking Component resolves by refId first, then by path. For example, if the French site uses `hst:pagenotfound = "error"` and its sitemap contains an item with `hst:refId = "error"` (such as `erreur`), the link will resolve to that item.
`hst:type`	`preview`	Type of the mount. The default is `live`.
`hst:types`	`mobile`	Additional (sub)type information. Used for cross-domain linking; the HST prefers mounts with the most `hst:types` in common with the current mount.
`hst:namedpipeline`	`defaultPipelineName`	Name of the pipeline to use for request processing.
`hst:isSite`	`true`	Deprecated in Hippo 10.
`hst:ismapped`	`true`	Indicates whether `hst:mountpoint` points to an `hst:site`. Use `false` for certain REST mounts. See REST Mount Property ismapped.
`hst:alias`	`site`	Alternate name for the mount, used for link creation regardless of the actual mount name.
`hst:authenticated` / `hst:roles` / `hst:users`	See Delivery Tier Authorization Configuration	Properties for securing a mount.
`hst:responseheaders`	`["Access-Control-Allow-Origin: http://localhost:3000", "Access-Control-Allow-Credentials: true"]`	Custom HTTP response headers for this mount and its descendant sitemap items, unless overridden. Use this for CORS or other header requirements. Set as a string array in the format `header_name:header_value`.
`hst:linkurlprefix1`	`https://www.example.org/foo`	URI schema, authority, and optional path to prefix fully qualified internal links.

1 Available since 14.2.1

Notes on `hst:homepage`

The hst:homepage property should reference a valid sitemap item refId for the homepage. This allows you to use the same value for different language sites by configuring the same refId, rather than using different sitemap item paths. You can also set hst:homepage to a language-specific path if needed. This property can be set per mount to support language or channel-specific homepages.

Securing Mounts

You can configure a mount to require authentication. When enabled, users must authenticate to access URLs for that mount.

Mount Points and Sites

The hst:mountpoint property specifies which (sub)site is used for the mount. Typically, hst:mountpoint points to a node of type hst:site under /hst:hst/hst:sites. For REST interfaces, this requirement may not apply.

For example, the hst:root mount might use /hst:hst/hst:sites/example, while the fr mount uses /hst:hst/hst:sites/example-fr. The nodes example and example-fr must be of type hst:site. Each hst:site node contains an hst:content property, which is the absolute JCR path to the site's content.

Example configuration:

/hst:hst:
  /hst:blueprints:
  /hst:channels:
  /hst:configurations:
  /hst:hosts:
    /dev-localhost:
      /hst:root:
        hst:mountpoint: /hst:hst/hst:sites/example
  /hst:sites:
    /example:
      hst:content: /content/documents/example
  /content:
    /documents:
      /example:
    /gallery:
    /assets:
    /attic:

To add a French site with its own content, create an additional hst:site node (e.g., example-fr) and a corresponding content node at /content/documents/example-fr.

Site Configuration and Sitemap

Each hst:site node can specify an explicit hst:configurationpath property pointing to an hst:configuration node. If this property is not set, the configuration is resolved by convention: the name of the hst:site node is used as {myproject} in /hst:hst/hst:configurations/{myproject}.

The configuration node at /hst:hst/hst:configurations/{myproject} is of type hst:configuration and typically contains the following structure. The hst:sitemap node defines how the remaining part of the URL (after mount matching) is handled, and how pages are rendered.

/hst:hst:
  /hst:configurations:
    /hst:default:
    /example:
      jcr:primaryType: hst:configuration
      /hst:abstractpages:
      /hst:catalog:
      /hst:components:
      /hst:pages:
      /hst:prototypepages:
      /hst:sitemap:
      /hst:templates:
      /hst:workspace:
  /hst:sites:
    /example:
      jcr:primaryType: hst:site

By default, it is recommended to rely on the convention-based configuration path, rather than explicitly setting hst:configurationpath. This approach keeps the configuration simpler and more maintainable.