HST Request Processing

1. Overview

The HST request processing model uses an inversion of control pattern. Request processing pipelines are assembled using Spring Framework configuration. The HST Container processes HTTP requests in a request/response flow, similar to the servlet model. Client agents, such as web browsers, send requests that the HST Container handles on the application server's thread. Request processing uses a pipeline structure, where configurable valves are plugged into the pipeline. You can configure the workflow and order of these valves in Spring Framework configuration files. Pipelines reference one or more valves through Spring dependency injection. Each valve is a Spring bean and can be assembled in the configuration.

2. Pipeline-Driven Processing

All requests to the HST Container enter through the HstFilter, which parses the URL and resolves the appropriate mount. You can map a request URL to a specific pipeline by setting the hst:namedpipeline property for a mount. By default, the site pipeline aggregates HST component pages.

HST-2 container pipelines dispatch requests to components and pages

Diagram: The diagram illustrates how the HST-2 Container routes different request URLs, such as site page and REST API URLs, to specific pipelines. These include the Default site pipeline, JAX-RS REST pipeline, Page composer pipeline, and custom pipelines. The Default site pipeline dispatches requests to HST components, while the REST pipeline invokes a JAX-RS component. The page is assembled from the component hierarchy and returned to the client.

3. Pipeline Architecture

In an HST application, each request is processed through a sequence of valves assembled as a pipeline.

When a request arrives, the system creates an HstRequestContext to manage processing through the pipeline.

HST request processing pipeline with context, valves, buffer, and component

Diagram: The diagram shows request processing through three areas: HstFilter, Container, and Component. The request enters via HstFilter, which creates an HstRequestContext. The request then passes through a pipeline of valves. After the pipeline, HstRequest and HstResponse are passed to a component. A buffer is also connected to the pipeline. The response returns through HstFilter to the client.

4. Pipeline Mapping Configuration

You configure pipeline mappings in classpath:/org/hippoecm/hst/site/container/SpringComponentManager-pipelines.xml.

<bean id="org.hippoecm.hst.core.container.Pipelines" class="org.hippoecm.hst.core.container.HstSitePipelines"> <property name="defaultPipelineName" value="DefaultSitePipeline"/> <property name="pipelines"> <map> <entry key="DefaultSitePipeline"> <bean class="org.hippoecm.hst.core.container.HstSitePipeline"> <property name="initializationValves"> <list> <ref bean="initializationValve"/> <ref bean="cmsSecurityValve"/> </list> </property> <property name="processingValves"> <list> <ref bean="securityValve" /> <ref bean="subjectBasedSessionValve" /> <ref bean="jcrSessionStatefulConcurrencyValve"/> <ref bean="contextResolvingValve" /> <ref bean="localizationValve" /> <ref bean="actionValve" /> <ref bean="resourceServingValve" /> <ref bean="pageInfoRenderingValve" /> <ref bean="esiPageInfoScanningValve" /> <ref bean="pageCachingValve"/> <ref bean="componentRenderingValve" /> <ref bean="aggregationValve" /> </list> </property> <property name="cleanupValves"> <list> <ref bean="cleanupValve"/> <ref bean="diagnosticReportingValve"/> </list> </property> </bean> </entry> </property> </bean>

This configuration defines three groups of valves for request processing:

  • initializationValves: Handles initialization tasks.
  • processingValves: Performs core request processing.
  • cleanupValves: Cleans up temporary data after processing.

Each group is a list of Spring beans that execute in order.

5. Request Handling with Components

The previous sections described internal pipeline processing in the HST Container. This section explains how the HST Container interacts with HST components during request processing.

A typical page request follows this sequence:

Sequence diagram of HST-2 request processing phases

Diagram: This sequence diagram shows the interactions between the Client, HST-2 Container, and three HstComponent instances: Parent, LeftChild, and RightChild. The process is divided into four phases: action, prepareBeforeRender, beforeRender, and render. The client submits a page action request, which is followed by a redirect to the render page and then a page render request. The container invokes doAction on RightChild, then calls prepareBeforeRender and doBeforeRender on Parent, LeftChild, and RightChild. During rendering, child components return their rendered content to Parent, and the container returns the aggregated page to the client.

Assumptions for this sequence:

  • The client requests a page mapped to a configuration with a root HST Component, "Parent".
  • At runtime, "Parent" contains two child components: "LeftChild" and "RightChild".
  • The client submits a form in the "RightChild" component using an HST Action URL.

The interaction proceeds as follows:

  1. The client sends a request to the HST Container using the HST Action URL.
  2. The container invokes doAction() on "RightChild" because the form was submitted via an Action URL.
  3. After doAction(), the container redirects to the render page. The container separates the action phase from the render phase to support aggregation of multiple components, following the POST/REDIRECT/GET (PRG) pattern.
  4. The client requests the render page.
  5. The container invokes prepareBeforeRender() on each component, if implemented. For details, see Parallel HstComponent Preprocessing.
  6. The container invokes doBeforeRender() on each component, in parent-to-child order.
  7. The container dispatches to each component's template render path, in child-to-parent order.
  8. A parent component's render template can include the rendered output of its child components, for example using the <hst:include /> tag.
  9. The container writes the aggregated content to the client.

If the page is requested via a GET method (not an Action URL), the sequence starts from step 4.

6. HstRequest and HstResponse

During all interactions between the HST Container and HST Components, the container provides each component with org.hippoecm.hst.core.component.HstRequest and org.hippoecm.hst.core.component.HstResponse objects.

HstRequest and HstResponse extend javax.servlet.http.HttpServletRequest and javax.servlet.http.HttpServletResponse. You can use standard servlet methods with these objects.

Additionally, HstRequest provides namespaced access to parameters and attributes for each component, as well as access to the HstRequestContext and the current lifecycle phase. Namespacing ensures that each HstComponent can read and write its own parameters and attributes without interfering with other components.

With HstResponse, a component can generate HST URLs, contribute head elements, and set HTTP headers. The component's template can delegate content generation to a servlet, JSP, or other template technology.

Share Feedback
Page: /build/request-handling/hst-2-request-processing
Section: Build
Category *