Handling custom localized error pages

[RNI76]

On our site, we'd like to be able to maintain and serve custom/localized  error pages in the end-users' own language rather than just a standard customized page like /apps/sling/servlet/errorhandler/404.jsp.

Right now, we're storing these localized pages as /content/<country>/<language>/errors/<errorcode>.html (e.g. /content/be/nl/errors/404.html), allowing editors to maintain them.

Normally, it wouldn't be hard to find and serve the correct page. You could just serve http://www.mysite.com/content/gb/en/errors/404.html if the users tries to fetch the non-existing page http://www.mysite.com/content/gb/en/invalidpage.html.

The problem is that we've got an Apache server doing rewriting in front of CQ like this:

/content/gb/en/products.html -> gb.mysite.com/products.html

- so when trying to determine which page to serve to the user, we use hard-coded reverse mappings (gb.mysite.com -> /content/gb/en/).

The thing is, the webmasters need to be able to set up error pages for a new country site without contacting a developer to get the mappings updated.

But how do I figure out which page to serve without using mappings?

Ideally, I'd like to use a "site setting" per site, allowing the webmaster to define e.g. /content/gb/en/errors as the "base path" for error pages. But when all I've got to go on is a request for e.g. http://gb.mysite.com/invalid.html, then all I can do is try to find the nearest correct parent that  resolves to a Page - which would then be "/". I thought I could somehow resolve the full path of this root Page to /content/gb/en/, but no luck.

Any ideas on how to handle this? Any and all suggestions would be most welcome!

[Ojjis]

Is there a reason that you don't let cq/sling do the mapping of the content instead?
 

[Ojjis]

Yes, I see the problem there.
The trivial case would be easy when you could use the nearest valid path. But as you've pointed out, if a request is made for http://gb.mysite.com/pagenoutfound.html then you could map the language part of the url to the corresponding language node (and then later decide what to do if the request is made to a page without any language domain eg. http://mysite.com/pagenoutfound.html). This if course only holds as long as the re-writing is done in the mysite.com/languange/ -> language.mysite.com but i guess thats what you are doing ?

So in this case I guess you found the best solution yourself :) but unfortunately I cannot figure out another way of solving it with the current Apache config.

[Ojjis · Accepted solution]

Oh ok, well you should still be able to actually use the request in this case (right?) since it actually requests a certain node/page (that does not exists).
If you create a filter or service it can then utilize the request path (from the request) and then serve the error page accordingly to your needs by calculating the path to the correct error page.

[RNI76]

Yup - I have access to the slingRequest variable as well as the other scripting variables provided by <cq:defineObjects />.

However, if a user tries to access http://gb.mysite.com/nonexistingpage.html, then the request path is "/nonexistingpage" which doesn't exist. The nearest valid parent path is then "/", which resolves to the root node. This leaves me with no way (that I can figure out :-)) to determine which error page to serve (apart from mapping the gb. part of the request to an actual country/language root node, like /content/gb/en).

If the user had requested http://gb.mysite.com/content/gb/en/nonexistingpage.html, then determining the correct error page would be trivial.

I guess that as long as I've got the Apache server messing up my paths, it's going to be hard to determine a correct page.. apart from storing the mappings in a globally maintainable place, which isn't really possible since all webmasters only have access to the setting for their own country site.

[Runal_Trivedi]

One way to solve this could be - maintain a map in etc/map for all domains versus their locale path.. in your error page then read the domain which you can resolve it to its corresponding content structure using resourceresolver. Once you have your content locale path, suffix it with error page identifier and serve the response.

[RNI76]

Which mapping? The "/content/gb.." -> "gb.mysite.com/.." which the Apache server is doing right now?

I'm not quite sure why it's set up like that - but it's not something I can change, unfortunately.

[RNI76]

Thanks for your input!

The problem is that the webmasters wouldn't be able to maintain the map in /etc/map.

For now, the solution has been to let them maintain the mappings in "site settings" for the standard global site. All the other sites then use those settings when mapping. Not the prettiest of solutions, but it works :-)