Url rewriter: site specific rules?


We have several sites on one bloomreach instance. We want to use the url rewriter for vanity urls and some other redirecting use cases we have. The issue we are hitting is that the rules seem to apply to all of the sites.

If I create a rule redirecting /vanity-url/ to /publication/2012/08/my-publicaiton-with-a-long-url it will work but will also be happening on sites other than the one it is intended for.

We would like a way to manage the redirects for each site independently. How can we create rules that apply to a specific site? We also want the rules to be portable to test environments so we do not want to include fully qualified urls in the rules. Any ideas on the best way to achieve this?

My first thought was something along the lines of:

  • create a folder per site under /content/urlrewriter
  • write our own version of HippoRewriteFilter thats distinguishes the site the request was for and invoke only rules from the relevant folder.

It seem like this could work but would create a maintenance issue for us. Is there a way to use the url rewriter out of the box to achieve this?



you can use advanced or xml rules and add host conditional, e.g:

<condition name="host" operator="equal">sub.mycompany.com</condition>
<to type="temporary-redirect">https://sub.mycompany.com/newfolder/$1/$2</to>

in advanced rule you can add multiple conditions, and combine them with or/and operators…
In xml you can use next attribute:

<condition name="host" operator="equal" next="or">sub.mycompany.com</condition>

<condition name="host" operator="equal">www.mycompany.com</condition>

Thanks - unfortunately I do not think that will work for us due to the way hippo is deployed. If I log the request in a servlet filter I see the the request url as:


… this is the server that has the delivery tier. This does not distinguish what site the request is for.

The method HstRequestUtils.getFarthestRequestHost(request) will return the relevant host but I do not think the logic contains can be captured in one fo these rules.

that is the case for everybody who is running a proxy in front.
We don’t check request url, we check against forwarded-for header, similar as in getFarthestRequestHost, you just need to setup your proxy server to forward those headers, but that is needed for HST to work properly anyway, so that should already be in place.

Ah, good to know - I will give that a try.