How to set ErrorDocument dynamically for different language

[girtorapankaj]

Hi,

In my current project, this is how we are setting ErrorDocument:

SetEnvIfNoCase Request_URI "^/(group|career|uk|se)/(en|sv)" MARKET=$1
SetEnvIfNoCase Request_URI "^/(group|career|uk|se)/(en|sv)" LANGUAGE=$2
# If market or language does not exists, they are set to default values
SetEnvIfNoCase MARKET ^\s*$ MARKET=group
SetEnvIfNoCase LANGUAGE ^\s*$ LANGUAGE=en

ErrorDocument 400 /%{ENV:MARKET}/%{ENV:LANGUAGE}/error-pages/4xx
ErrorDocument 401 /%{ENV:MARKET}/%{ENV:LANGUAGE}/error-pages/4xx
ErrorDocument 403 /%{ENV:MARKET}/%{ENV:LANGUAGE}/error-pages/4xx
ErrorDocument 404 /%{ENV:MARKET}/%{ENV:LANGUAGE}/error-pages/4xx
ErrorDocument 405 /%{ENV:MARKET}/%{ENV:LANGUAGE}/error-pages/4xx

And, its working fine. Now major concern is whenever a new market or new language in existing market is added, we need to change search criteria in dispatcher. Is there any way to dynamically populate the market and language in apache dispatcher config instead of using hard coded values?

[Ritesh_Mittal · Accepted solution]

Hi @girtorapankaj ,

Instead of configuring error pages from dispatcher you can write custom error handler and using that can redirect to specific error pages. There is a explanation here

[Umesh_Thakur]

Instead of hardcoding it you should go for the variable based for each region and configure it in region specific virtualhost like 

##Brazil##

<VirtualHost *:8080>

ServerName ${BR_VH}

Include conf/dispatcher-handler.conf

Define AEM_CONTENT_ROOT_PATH /content/we-retail/br

DocumentRoot /app/HTTPServer/cache/content/we-retail/br

Include browser_cache.conf

Include rewrite.conf

</VirtualHost>

Here you can include your error handler path.

Hope this will help.

Umesh Thakur

[girtorapankaj]

Adding new host file for each market and language would be very tedious. As of now, we support 4 markets and each market supports 2 languages so If we go with this solution, then we need to have 8 different host file and in future if there are more markets and language gets added, this process would become more tedious.

[Umesh_Thakur]

why you need to have 8 different vhost file? I think there is some confusion..!

you can create single virtualhost.conf file for your entire application and there you can create section for every locale and put your configuration there like:

##Brazil##

<VirtualHost *:8080>

ServerName ${BR_VH}

Include conf/dispatcher-handler.conf

Define AEM_CONTENT_ROOT_PATH /content/we-retail/br

DocumentRoot /app/HTTPServer/cache/content/we-retail/br

Include browser_cache.conf

Include rewrite.conf

</VirtualHost>

##Germany##

<VirtualHost *:8080>

ServerName ${BR_VH}

Include conf/dispatcher-handler.conf

Define AEM_CONTENT_ROOT_PATH /content/we-retail/br

DocumentRoot /app/HTTPServer/cache/content/we-retail/br

Include browser_cache.conf

Include rewrite.conf

</VirtualHost>

then where ever you need any dynamic value you can get it from the variable like ${BR_VH} 

Now I think everything is clear

Hope this will help.

Umesh Thakur

[girtorapankaj]

Hi Umesh,

Thanks for clarifying. 

But issue is when ever a new market/language gets added, we need to update the variable(s) to include that market or language. This is what we want to avoid.

Would it be possible for you to share your contact no so that I can explain in details with more information.

Regards

Pankaj

[markus_bulla_adobe]

Hi @girtorapankaj!

Actually, your solution looks quite good to me. If you want it to be more generic, you could replace the regular expressions in the first two lines with something like

SetEnvIfNoCase Request_URI "^/(group|career|[a-z]{2})/([a-z]{2})" MARKET=$1

 If you are able to produce a dispatcher/vhost configuration that does not need additional maintenance/configuration for future languages and markets depends primarily on your content structure. The default, most recommended structure usually has a "/MARKET/LANGUAGE" part in it as per your example. Personally, I always recommend to stick to standard country and language two-letter ISO codes here. That makes a lot of things much easier. In your example, you have some dissenting market identifiers ("group", "career"). While there may be good reasons and totally valid business cases behind that decision it makes things a bit more difficult when it comes to producing generic, low-/non-maintenance configurations. However, if you are able to stick to these two-letter codes in the future a configuration with my example regular expression will work without additional changes.

While the solution that @Ritesh_Mittal proposed is also another valid approach, I recommend to handle the most basic configurations on dispatcher level. The reason behind that gets a bit clearer if you look not only at the 4xx error code range but also the 5xx HTTP status codes. If your AEM instance is in any kind of trouble (e. g. down or any other error state) and returns a HTTP 500 status it is very likely that it will not be able to actually render a nicely styled error page for that status code and send it to the end user.

My recommendation is:

• Let AEM render your error pages. They can be fully flexible and authored by your content editors, just as normal content pages in AEM.
• Have some kind of ErrorDocument configuration in your dispatcher configuration pointing to these AEM pages. Your example config looks totally fine to me. Please also refer to my adjusted, more generic regular expression for the market/language mapping.
  Please note: your approach is more of an allow list of possible error pages. This is a bit stricter compared to the more generic solution but also requires more maintenance. On the other hand the more generic approach would allow a visitor to request something like "/zz/zz/" and the dispatcher would still try to serve that error page, which would not be the case for your stricter allow list approach. You need to decide where your priority lies.
• If possible, design your content structure to use two-digit country and language ISO codes for market and language.
• Make sure your error pages are/can be cached on the dispatcher. This way they can be server even if your AEM instance is not in a healthy state (as an error code may indicate).
• Bonus: have some kind of script that runs on your dispatcher on a regular basis to pull the error pages from AEM and put them into the dispatcher cache (e. g. cronjob). This way they are always available if you need them.
• As a backup solution you may want to have a static error page outside of the cache directory that is served as a last resort fallback.

Apart from that you may also want to check the ACS AEM Commons Error Page Handler.

Hope that helps!