Mount Matching
AMount is the mapping between someURL prefix and a(sub)site. AMount directly below the virtual host has the mandatory namehst:root, and is equivalent to“/” . ThisMount matches everyURL. When the rootMount contains a child node who's name is equal the next path segment in theURL, thisMount is matched. A path segment is the part of aURL between two slashes. The matched child mount can again contain child mounts: the mount configuration is acomposite (tree) structure, where any mount can contain child mounts. For matching, the deepestMount that matches theURL 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:root2. http://localhost:8080/news/2011 --> hst:root3. http://localhost:8080/fr --> fr4. http://localhost:8080/fr/news --> fr5. http://localhost:8080/de --> de
Because theMount 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 theFrench mount fr. Hence the followingURLs would map as follows:
1. http://localhost:8080/fr --> fr2. http://localhost:8080/fr/news --> fr3. http://localhost:8080/fr/sub1 --> fr/sub14. http://localhost:8080/fr/sub2/news --> fr/sub2
Mount nodes have some mandatory and optional configuration properties. AMount inherits properties from its parentMount, and theroot Mount inherits its properties from theVirtualhost it belongs to.
OnMount nodes you only need to configure properties that are different from parent configuration nodes.
The most important configuration property of aMount is thehst:mountpoint. This is the absoluteJCR path to thehst: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 thehst:site containing information about the content and configuration for thisMount |
hst:homepage | home | The sitemap itempath of the home page when the URL ends at exactly theMount, for example when the URL is/. The property can also be a sitemap itemrefId of the home page, instead of a sitemap item path. HST Linking Component will look up aSiteMapItem byrefId first, and it will look up aSiteMapItem bypath 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 onrefId. If not found byrefId, it will look up a sitemap item by resolving it simply based onpath. |
hst:locale | en_US | The locale information for this Mount: this locale is also set on theHttpServletRequest and thus using I18nResourceBundles 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:type | preview | The type of the Mount. Default it islive. |
hst:types | mobile | Extra (sub)type information. Can be used to give the HST extra hints to prefer to link to someMount in case of cross domain linking. In case of cross domain linking, the HST prefers Mounts that have mosthst: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 thehst:mountpoint points to a hst:site. Only use false for certain REST mounts. Also seeREST 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 | 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
Thehst:homepage property can best contain a validrefId value pointing to itshomepage sitemap item. So, you can have the same value for bothEnglish site andFrench site by configuring the samerefId value instead of using different sitemap item paths. Alternatively, it is also possible to have thehst:homepage property for aFrench site to beaccueil instead ofhome. This can be very nicely configuredperMount to support language per site and per channel.
It is also possible toconfigure aMount to be secured, in other words, that you need to authenticate when you want to access aURL for that Mount.
As already mentioned, thehst:mountpoint contains the information about which(sub)site must be used for theMount. In general ahst:mountpoint always points to a node of typehst:site below the/hst:hst/hst:sites. There is a special case, mainly forREST-interfaces where this is not needed. Thus, for example, thehst:root mount has ahst:mountpoint to/hst:hst/hst:sites/example and thefr mount to/hst:hst/hst:sites/example-fr. The nodesexample andexmple-fr must be of typehst:site. Thehst:site nodes contain a propertyhst:content that is the absoluteJCR path to the content for the site.
Thehst:site nodes for the hosts configuration with only one site namedexample 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 extrahst:site nodes, namelyexample-fr, and an extra content entry/content/documents/example-fr.
Thehst:site node (example) also points to a configuration with anhst:sitemap that contains information for a(sub)site how the remainer of theURL after the matchedMount is matched, and how subsequently a page is rendered (request processing). This configuration is configured at/hst:hst/hst:configurations/{myproject}. Anhst:site can have an explicit propertyhst:configurationpath pointing to somehst:configuration, or, if it is missing, it takes the configuration by convention: The name of thehst:site is filled in for{project} for/hst:hst/hst:configurations/{myproject} and that is the location where thehst:configuration is looked up from. Preferred is to not explicitly configure thehst:configuration location but to keep it by convention.
The node at/hst:hst/hst:configurations/{myproject} is of typehst:configuration, and contains by default the structure below. Thehst:sitemap contains the configuration for the last part of the request matching. The rest of the configuration likehst: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