Troubleshooting: URLs are cached with the wrong hostname

Problem

If a WebSphere Commerce storefront is accessible from more than one host name (for example, http://abc.com/en/aurora and http://xyz.com/en/aurora), then the caching implementation must be revisited. By default, full URLs are used for store page links to ensure that standard pages use the HTTP protocol, and secure pages use the HTTPS protocol. With this implementation, when the HTML response is cached, the full URLs, including the host name, also get cached. Thus, if a shopper accesses a page through the first host name, they might be served the contents from cache wherein the links point to the second host name. In this event, the URLs being displayed in the shopper's browser links and address bar can switch back and forth between host names. This site behavior is inconsistent and potentially confusing.

Solution

Two options exist that can be used to mitigate this behavior:
  1. Option #1: Make the host name part of the cache-id in the cachespec.xml file. Page content is then cached based on the host name parameter. The disadvantage of this approach is that each host name creates a separate copy of the cache. This increases cache load and size, negatively affecting site performance.
    <component id="host" type="header">
	<required>true</required>
</component>
  2. Option #2: Use relative URLs to build links. With relative URLs, cached page links do not include the host name, protocol, or port number. Therefore, the host name that the shopper enters from is persisted across pages. The disadvantage to using this method is that standard pages might be served over HTTPS, negatively affecting site performance.

    For instructions on how to implement relative path URLs, see Tag: url.