This article covers a Bloomreach Experience Manager version 11. 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           [hst:virtualhosts]
    + dev-localhost     [hst:virtualhostgroup]
    | + localhost       [hst:virtualhost]
    + test-env          [hst:virtualhostgroup]
    | + com             [hst:virtualhost]
    |   + example       [hst:virtualhost]
    |     + test        [hst:virtualhost]
    + acct-env          [hst:virtualhostgroup]
    |  + com            [hst:virtualhost]
    |    + example      [hst:virtualhost]
    |       + acct      [hst:virtualhost]
    + prod-env          [hst:virtualhostgroup]
       + com            [hst:virtualhost]
         + example      [hst:virtualhost]
           + www        [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 a link will never resolve to as this would imply a link from prod-env to acct-env.

  2. Have the following available hosts:



Note that, 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


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           [hst:virtualhosts]
    + dev-localhost     [hst:virtualhostgroup]
    | + locahost        [hst:virtualhost]
    + test-env          [hst:virtualhostgroup]
    | + com             [hst:virtualhost]
    | |  + example      [hst:virtualhost]
    | |    + test       [hst:virtualhost]
    | + fr              [hst:virtualhost]
    |   + example       [hst:virtualhost]
    |     + test        [hst:virtualhost]
    + acct-env          [hst:virtualhostgroup]
    | + com             [hst:virtualhost]
    | |  + example      [hst:virtualhost]
    | |     + acct      [hst:virtualhost]
    | + fr              [hst:virtualhost]
    |   + example       [hst:virtualhost]
    |     + acct        [hst:virtualhost]
    + prod-env          [hst:virtualhostgroup]
       + com            [hst:virtualhost]
       |  + example     [hst:virtualhost]
       |    + www       [hst:virtualhost]
       + fr             [hst:virtualhost]
          + example     [hst:virtualhost]
            + www       [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:

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.

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?