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
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?
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_M 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.