Recently, I faced an issue in one of the site of a Sitecore Multi-Site solution. A request was redirected multiple times and chrome was throwing request redirected too many times error.
The request was for a Not Found Page item and seems like that item was not found and it was again redirecting to Not Found Page Item. Except that item was present in the content tree and it was accessible via URL as well.
Upon deep analysis, identified that in the failure case, the language code used to access that item was different. Say for eg.,
www.mark3.com/en/product/NotFound – success scenario
www.mark3.com/en-us/product/NotFound – failure scenario
Not Found item had only en version and no en-us version. So, if the request comes for /en-us/product/NotFound it wouldn’t exist in Sitecore and it was redirected to /product/NotFound.
Keeping this aside,
Now, Sitecore has a Sitecore.Pipelines.PreprocessRequest.StripLanguage processor that based on the Sitecore setting – Languages.AlwaysStripLanguage strips the langauge code, if it comes immediately after the host name.
Meaning,
www.mark3.com/en/product/NotFound will be resolved to www.mark3.com/product/NotFound With language version as ‘en’.
Now, coming back to the issue, thus, /product/NotFound was redirecting to /product/NotFound and hence, the circular redirection. To fix it, if the Languages.AlwaysStripLanguage property should be set to false, that would treat the component immediately after the host name as a sitecore content tree item and process accordingly.
So set that property to false and now tested the failure scenario and it was working fine redirected to /product/NotFound with out any issues.
But, when in a multisite solution, when one site needs the language code after domain name and at the same time, no language folder is to be created in the sitecore content tree, this would cause an issue if not handled properly.
www.mark1.com/es/Careers/Marketing
So, to fix this, thought of patching the Strip Language processor and enabling/disabling the Languages.AlwaysStripLanguage with a custom site property – site wise.
Another road block, StripLanguage processor comes under PreprocessRequest Pipeline and Sitecore.Context.Site is setup in the HttpRequest pipeline – SiteResolver processor. Meaning we can’t access the site property in the Strip Language processor unless we write some logic to call SiteResolver methods from StripLanguage Processor.
These are making all things complex. So, to resolve this simply, we can use the virtual path attribute of Site Property.
In the site definition, for the www.mark1.com created two sites which differs by virtual path. Meaning /en as virtual path for one site and /es as virtual path for another site. With the languages set to en and es accordingly.
This can be applied for all the sites that has similar requirement in the multi site instance.
P.S: The Strip Language processor, gets the SitecoreContext.Language and SitecoreContext.Data.FilePath properties from arguments. But when I tried to replicate the same in my Custom Strip Language Processor, I got can’t be accessed error. Upon checking this, identified, SitecoreContext is of internal access specifier and again, we have to do a work around for this. Hence, the Site definition approach.
Sitecore Blog 