HST Request Matching

During Request Matching phase, an incoming URL is attempted to be matched to a SiteMapItem in the following order:

1. Hostname (and an optional port number)
2. Mount
3. SitemapItem

If somewhere in the chain a match cannot be found a HttpServletResponse.SC_NOT_FOUND is returned

The HST configuration is stored in the repository. The default location for the configuration is below

/hst:hst 

It must contain at least the main nodes hst:hosts, hst:sites and hst:configurations. Typically also the nodes hst:blueprints and hst:channels are configured though not strictly mandatory for the HST to handle requests: they are not needed at all for the Request Matching phase. The hst:channels node is needed if you want to be able to manage your changes in the ChannelManager. The hst:blueprints is only needed when you want to be able to create new channels from the ChannelManager. By default, the /hst:hst configuration looks something like:

+ hst:hst
    + hst:blueprints
    + hst:channels
    + hst:configurations
    + hst:hosts
    + hst:sites

Through the Request Matching in the HST, a single HST application supports multiple sites (1000+ sites are supported) running on different hosts. The HST also takes care of cross domain (host) linking between documents belonging to different sites.

Typically, an Apache HTTP Server (httpd) configuration for our production environments just forwards any request to the HST application, which in turns does the host and URL matching of the original request. (Sub)sites can be added on the fly without the need to restart httpd or any other application.