HST Request Matching

The HST request matching process determines how incoming URLs are mapped to SiteMapItems. The matching sequence follows this order:

Hostname (and optional port number)
Mount
SitemapItem

If the request cannot be matched at any stage, the system returns HttpServletResponse.SC_NOT_FOUND.

HST Configuration Structure

The HST configuration is stored in the Java Content Repository (JCR). By default, the configuration resides at:

/hst:hst

This node must include at least the following main child nodes:

hst:hosts
hst:sites
hst:configurations

The hst:blueprints node is commonly present but is not required for request matching. It is only necessary if you want to create new channels using the Channel Manager. A typical /hst:hst structure appears as follows:

/hst:hst:
  /hst:blueprints:
  /hst:configurations:
  /hst:hosts:
  /hst:sites:

Multi-Site and Cross-Domain Support

The HST request matching mechanism allows a single HST application to serve multiple sites—scaling to over a thousand sites—across different hosts. The HST also manages cross-domain (host) linking between documents in separate sites.

Integration with Apache HTTP Server

In production environments, Apache HTTP Server (httpd) is typically configured to forward all requests to the HST application. The HST application then performs host and URL matching for each request. You can add or update (sub)sites dynamically without restarting httpd or the HST application.

Note: For details on configuring Apache HTTP Server as a reverse proxy, see Configure Apache HTTP Server as Reverse Proxy for Hippo.