Bloomreach

Bloomreach Documentation version

Hostname Matching

During this phase, the hostname of the HttpServletRequest is attempted to be matched to a configured virtualhost in the HST configuration. For the hostname, the Host (or X-Forwarded-Host request header if present) is used, which returns the original host information as requested by the client. Virtualhosts are configured in reversed hierarchy. So assume we have the configuration as follows:

/hst:hst:
  /hst:hosts:
    jcr:primaryType: hst:virtualhosts
    /dev-localhost:
      jcr:primaryType: hst:virtualhostgroup
      /localhost:
        jcr:primaryType: hst:virtualhost
    /test-env:
      jcr:primaryType: hst:virtualhostgroup
      /com:
        jcr:primaryType: hst:virtualhost
        /example:
          jcr:primaryType: hst:virtualhost
          /test:
            jcr:primaryType: hst:virtualhost
    /acct-env:
      jcr:primaryType: hst:virtualhostgroup
      /com:
        jcr:primaryType: hst:virtualhost
        /example:
          jcr:primaryType: hst:virtualhost
          /acct:
            jcr:primaryType: hst:virtualhost
    /prod-env:
      jcr:primaryType: hst:virtualhostgroup
      /com:
        jcr:primaryType: hst:virtualhost
        /example:
          jcr:primaryType: hst:virtualhost
          /www:
            jcr:primaryType: hst:virtualhost

This means we:

  1. Have four environments ( virtualhostgroups), dev-localhost, test-env, acct-env and prod-env. We separate environments because the HST supports cross-domain linking out-of-the-box, but we do not want links ever to be created between different environments. The HST will never create a link between different virtualhostgroups. Thus for example from www.example.com a link will never resolve to acct.example.com as this would imply a link from prod-env to acct-env.

  2. Have the following available hosts:

    localhost
test.example.com
acct.example.com
www.example.com

     

Note that example.com, and even com are also valid hosts, but, as will be explained below, a host only becomes a host the HST can match when there is at least a hst:root node below it of type hst:mount. So, if the node

/hst:hst/hst:hosts/com/example

would get a node hst:root attached to it, then it would become a real possible host.

If you want to add besides the .com hosts also .fr hosts (and sites), the host configuration would become:

/hst:hst:
  /hst:hosts:
    jcr:primaryType: hst:virtualhosts
    /dev-localhost:
      jcr:primaryType: hst:virtualhostgroup
      /locahost:
        jcr:primaryType: hst:virtualhost
    /test-env:
      jcr:primaryType: hst:virtualhostgroup
      /com:
        jcr:primaryType: hst:virtualhost
        /example:
          jcr:primaryType: hst:virtualhost
          /test:
          jcr:primaryType: hst:virtualhost
      /fr:
        jcr:primaryType: hst:virtualhost
        /example:
          jcr:primaryType: hst:virtualhost
          /test:
            jcr:primaryType: hst:virtualhost
    /acct-env:
      jcr:primaryType: hst:virtualhostgroup
      /com:
        jcr:primaryType: hst:virtualhost
        /example:
          jcr:primaryType: hst:virtualhost
          /acct:
            jcr:primaryType: hst:virtualhost
      /fr:
        jcr:primaryType: hst:virtualhost
        /example:
          jcr:primaryType: hst:virtualhost
          /acct:
            jcr:primaryType: hst:virtualhost
    /prod-env:
      jcr:primaryType: hst:virtualhostgroup
      /com:
        jcr:primaryType: hst:virtualhost
        /example:
          jcr:primaryType: hst:virtualhost
          /www:
            jcr:primaryType: hst:virtualhost
       /fr:
         jcr:primaryType: hst:virtualhost
         /example:
           jcr:primaryType: hst:virtualhost
           /www:
             jcr:primaryType: hst:virtualhost

The com nodes are the same as before, but, there have also been added the fr hosts. Now, also the following extra hosts are available:

test.example.fr
acct.example.fr
www.example.fr

There has not been added a new French host for localhost. On local development, you normally just want to access all sites over localhost. See Mount Matching how this is normally done.

Properties on a VirtualHost

Property name

Example

Description

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 virtual host, and its descendant mounts and sitemap items unless the property is overriden. For example, when Cross-Origin Resource Sharing (CORS) is required, 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:allowedorigins1 ["http://www.example.com", "http://localhost:3000"]

List of origins allowed to make cross-origin requests. Enables allowing of more than one origin. When an allowed origin makes a request, the Access-Control-Allow-Origin response header will be set to that origin.

If the Access-Control-Allow-Origin header is defined in hst:responseheaders (see above), hst:allowedorigins is ignored.

This property is to be set to a string array, each of which should be in the form of a host ( protocol + hostname + port ) like the example on the left.
hst:linkurlprefix2 https://www.example.org URI schema, authority, and optional path to prefix fully qualified internal links with.
hst:cdnhost //cdn.example.org

CDN host to serve static and/or binary files from. See Serve Gallery Images, Assets, Web Files, and Static Webapp Files from a CDN for details.

If both hst:linkurlprefix and hst:cdnhost are present, hst:cdnhost takes precedence.

1 Available since v14.1.0

2 Available since v14.2.1

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?