Bloomreach

Bloomreach Documentation version

This article covers a Bloomreach Experience Manager version 12. There's an updated version available that covers our most recent release.

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.

When there is no matching virtualhost for the hostname, a default host can be returned (for example localhost). This can be configured on the hst:hosts node with hst:defaulthostname property.

@hst:responseheaders on a VirtualHost

Property name

Example

Description

hst:responseheaders

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

Applicable since Bloomreach Experience Manager 12.3.0.

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 with this sitemap item, 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.
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?