This article covers a Bloomreach Experience Manager version 13. There's an updated version available that covers our most recent release.

Site HTTPS troubleshooting

Before we introduced seamless http/https support, the HST used to be scheme agnostic: It did not matter whether a request was over http or https. The HST would just serve the response regardless its scheme. All fully qualified created links by default where over http. Typically in front of the HST there was something like a httpsfilter that did a client side redirect from http to https or vice versa.

Since the introduction of seamless http/https support, the HST does a check of the visitor request scheme against the scheme on the host/mount/sitemapitem that was matched for the request. If the schemes are not inline, the HST by default does a client side redirect to the correct scheme. Since the default scheme is http, you need to adjust some HST configuration if you want to have custom valves / hst components redirecting to https, use the httpsfilter, or if you want to run the container (ie tomcat) with SSL support.

Custom https redirecting code

If you have custom java code (for example a HstComponent class) that (conditionally) redirects http to https, and or vice/versa you might have to set the hst configuration to

hst:schemeagnostic: true

You can do this on host, mount or sitemapitem level. Setting the HST to be scheme agnostic results in the HST pre 7.8.x behavior.

If however, you prefer to have the seamless https support from the HST, and have your own custom redirects, possibly through a custom https support valve, you should not set the HST to behave scheme agnostic. In this case, the best solution is to configure on a hst:virtualhost node the following property:

hst:customhttpssupport: true

The above property results in the following behavior:

If a request is done over https and it hit the HST web application, it gets rendered regardless whether the matched mount or sitemapitem indicates the request should be served over http.

The property is mainly there to avoid browser redirect loops, as some custom java class might indicate the request must be over https, while the matched sitemapitem indicates it must be over http. With hst:customhttpssupport set to true, the request will be served over https.

SSL support on container (ie tomcat) level

Note: in general we recommend https offloading to a reverse proxy, eg httpd, instead of configuring the container for SSL support. In case of SSL offloading, make sure to set the X-Forwarded-Proto header by the proxy that does the offloading, see configure apache http server as reverse proxy for hippo.

After you configured the container for SSL support, for example see  https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html, you need to configure in the hst configuration that https requests only are allowed. This can be done in two ways:

  1. Set the default scheme for all hosts to https. This can be done by setting hst:scheme = https for /hst:hst/hst:hosts.
  2. Set on all the root hst:virtualhost nodes the property hst:schemeagnostic = true.
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?