HST Request Matching

DuringRequest Matching phase, an incomingURL is attempted to be matched to aSiteMapItem 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 aHttpServletResponse.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 nodeshst:hosts,hst:sites andhst:configurations. Typically also the nodeshst:blueprints are configured though not strictly mandatory for the HST to handle requests: they are not needed at all for theRequest Matching phase. Thehst:blueprints is only needed when you want to be able to create new channels from theChannelManager. By default, the/hst:hst configuration looks something like:

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

Through theRequest Matching in the HST, a single HST application supports multiple sites (1000+ sites are supported) running on different hosts. The HST also takes care ofcross 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 andURL matching of the original request. (Sub)sites can be added on the fly without the need to restarthttpd or any other application.