Mount Matching

A Mount is the mapping between some URL prefix and a (sub)site. A Mount directly below the virtual host has the mandatory name hst:root, and is equivalent to “/” . This Mount matches every URL. When the root Mount contains a child node who's name is equal the next path segment in the URL, this Mount is matched. A path segment is the part of a URL between two slashes. The matched child mount can again contain child mounts: the mount configuration is a composite (tree) structure, where any mount can contain child mounts. For matching, the deepest Mount that matches the URL is matched and used during further request processing.

Assume the following configuration for development:

/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

Now the follow URLs map to the following Mounts (assuming the contextpath empty):

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

Because the Mount configurations is a composite pattern, the following configuration is also possible:

/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 the example above, there are two separate extra subsites for the French mount fr. Hence the following URLs would map 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 nodes have some mandatory and optional configuration properties. A Mount inherits properties from its parent Mount, and the root Mount inherits its properties from the Virtualhost it belongs to.

On Mount nodes you only need to configure properties that are different from parent configuration nodes.

The most important configuration property of a Mount is the hst:mountpoint. This is the absolute JCR path to the hst:site node that contains the content and the configuration for this Mount. Other important properties are listed below. Note that these are only the most important properties.

Property name

Example

Description

hst:mountpoint

/hst:hst/hst:sites/example

The location of the hst:site containing information about the content and configuration for this Mount

hst:homepage

home

The sitemap item path of the home page when the URL ends at exactly the Mount, for example when the URL is /.

The property can also be a sitemap item refId of the home page, instead of a sitemap item path. HST Linking Component will look up a SiteMapItem by refId first, and it will look up a SiteMapItem by path if not found. For example, a mount of the French locale has ' hst:homepage = "home"' and its sitemap has ' accueil' sitemap item only (without 'home' sitemap item) which has ' hst:refId = "home"', then HST Linking Component will create a link to ' accueil' sitemap item by resolving it based on refId. If not found by refId, it will look up a sitemap item by resolving it simply based on path.

hst:locale

en_US

The locale information for this Mount: this locale is also set on the HttpServletRequest and thus using I18n ResourceBundles can be used without further having to set the Locale.

hst:pagenotfound

404page

The link to create when the HST cannot create a link for some document.

The property can also be a sitemap item refId of the pagenotfound page, instead of a sitemap item path.
HST Linking Component will look up a SiteMapItem by refId first, and it will look up a SiteMapItem by path if not found.
For example, a mount of the French locale has 'hst:pagenotfound = "error"' and its sitemap has ' erreur' sitemap item only (without 'error' sitemap item) which has 'hst:refId = "error"', then HST Linking Component will create a link to ' erreur' sitemap item by resolving it based on refId. If not found by refId, it will look up a sitemap item by resolving it simply based on path.

hst:type

preview

The type of the Mount. Default it is live.

hst:types

mobile

Extra (sub)type information. Can be used to give the HST extra hints to prefer to link to some Mount in case of cross domain linking. In case of cross domain linking, the HST prefers Mounts that have most hst:types in common with the current Mount.

hst:namedpipeline

defaultPipelineName

The pipeline to use for the request processing

hst:isSite

true

This property has been deprecated in Hippo 10.

hst:ismapped

true

Whether the hst:mountpoint points to a hst:site. Only use false for certain REST mounts. Also see REST Mount Property ismapped.

hst:alias

site

The name of the mount which you can use to create a link for, regardless of the name of the mount.

hst:authenticated / hst:roles / hst:users

See Delivery Tier Authorization Configuration

Securing a Mount

hst:responseheaders

["Access-Control-Allow-Origin: http://localhost:3000", "Access-Control-Allow-Credentials: true"]

Custom HTTP Response Header(s) to be always written for a request on this mount, and its descendant sitemap items unless the property is overriden. For example, when Cross-Origin Resource Sharing (CORS) is required with this mount, you can configure related response headers through this property.

This property is to be set to a string array, each of which should be in the form of ( header_name + ':' + header_value ) like the example on the left.

hst:linkurlprefix1 https://www.example.org/foo URI schema, authority, and optional path to prefix fully qualified internal links with.

1 Available since 14.2.1

The hst:homepage property can best contain a valid refId value pointing to its homepage sitemap item. So, you can have the same value for both English site and French site by configuring the same refId value instead of using different sitemap item paths. Alternatively, it is also possible to have the hst:homepage property for a French site to be accueil instead of home. This can be very nicely configured per Mount to support language per site and per channel.

It is also possible to configure a Mount to be secured, in other words, that you need to authenticate when you want to access a URL for that Mount.
As already mentioned, the hst:mountpoint contains the information about which (sub)site must be used for the Mount. In general a hst:mountpoint always points to a node of type hst:site below the /hst:hst/hst:sites. There is a special case, mainly for REST-interfaces where this is not needed. Thus, for example, the hst:root mount has a hst:mountpoint to /hst:hst/hst:sites/example and the fr mount to /hst:hst/hst:sites/example-fr. The nodes example and exmple-fr must be of type hst:site. The hst:site nodes contain a property hst:content that is the absolute JCR path to the content for the site. 
The hst:site nodes for the hosts configuration with only one site named example results in :

/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:     

If to the above configuration, we want to add a French site which has its own content, there would be besides the host configuration we saw before for example an extra hst:site nodes, namely example-fr, and an extra content entry /content/documents/example-fr.
The hst:site node ( example) also points to a configuration with an hst:sitemap that contains information for a (sub)site how the remainer of the URL after the matched Mount is matched, and how subsequently a page is rendered (request processing). This configuration is configured at /hst:hst/hst:configurations/{myproject}. An hst:site can have an explicit property hst:configurationpath pointing to some hst:configuration, or, if it is missing, it takes the configuration by convention: The name of the hst:site is filled in for {project} for /hst:hst/hst:configurations/ {myproject} and that is the location where the hst:configuration is looked up from. Preferred is to  not explicitly configure the hst:configuration location but to keep it by convention.

The node at /hst:hst/hst:configurations/{myproject} is of type hst:configuration, and contains by default the structure below. The hst:sitemap contains the configuration for the last part of the request matching. The rest of the configuration like hst:components, hst:pages, hst:template, etc is for the request processing.

/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

 

Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?