At Visus, LLC, we pride ourselves on solving complex technical challenges for our clients across various industries. Recently, we faced a particularly tricky issue when working with a client who was implementing the ASP.NET Core rendering engine in conjunction with Sitefinity. The goal was to leverage the modern editing experience and enhanced performance of the ASP.NET Core pages. However, during the setup, a key obstacle emerged: a redirect issue caused by the X-Original-Host header, preventing the system from working as intended.
In this blog post, we’ll walk through the unique solution that resolved this issue and how it can help others facing similar challenges with Azure App Services and Sitefinity’s ASP.NET Core rendering engine.
The Problem: Redirects and Header Errors
While setting up the ASP.NET Core rendering engine, the system began redirecting to the CMS URL when attempting to log into the backend. The diagnostics page displayed an error related to the X-Original-Host header. Specifically, the error message indicated that:
“The sent host header value (X-Original-Host) – ‘{renderer URL}’ is not rewritten to the value of the Host Header – ‘{CMS URL}’. Check your URL rewriter settings in the web.config file.”
At this stage, it was clear that the issue involved a misalignment between the X-Original-Host header sent by the rendering engine and the Host Header used by the CMS. Understanding and addressing this discrepancy was key to resolving the issue.
The Root Cause: Azure App Services and the Application Gateway Host Rewrite Module
The core challenge stemmed from the deployment setup on Azure App Services, where both the CMS and the Rendering Engine were hosted. As it turns out, there is a crucial step required to ensure the Application Gateway Host Rewrite Module extension works as expected in this context. Without this step, the header rewrite process fails, leading to the error we encountered.
The Solution: ApplicationHost.xdt File for Header Rewrite
After verifying the setup instructions multiple times and ruling out other potential causes, the solution became clear: it was necessary to add an applicationHost.xdt file to the parent directory of the CMS app in Azure.
In Azure App Services, the site is deployed to the C:/home/site/wwwroot/ directory. To address the issue, the next step involved using Kudu (accessible through the “Advanced Tools” option in the Development Tools section of the Azure App Service blade) to create an applicationHost.xdt file in the parent directory: C:/home/site/.
Once the file was created, it needed to be populated with the following content:
<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<system.webServer>
<rewrite>
<allowedServerVariables xdt:Transform="Replace">
<add name="HTTP_X_ORIGINAL_HOST" xdt:Transform="InsertIfMissing" />
<add name="HTTP_HOST" xdt:Transform="InsertIfMissing" />
</allowedServerVariables>
</rewrite>
</system.webServer>
</configuration>
This file specifically allows the necessary HTTP headers—HTTP_X_ORIGINAL_HOST and HTTP_HOST—to be inserted if missing and ensures that the rewrite process occurs as expected. Importantly, this step was required on the CMS app service, not on the rendering engine itself.
Final Steps: Restarting the CMS App Service
After adding and saving the applicationHost.xdt file, the next step was to restart the CMS app service. Upon restarting, the rendering engine began functioning correctly, eliminating the redirect issue and allowing the CMS to work as intended.
Lessons Learned: A Clear Path Forward
This issue was a challenging one to diagnose, but it offered valuable insights into how the Application Gateway Host Rewrite Module works in the context of Azure App Services. A key takeaway was the realization that certain server variables, such as HTTP_X_ORIGINAL_HOST and HTTP_HOST, need to be explicitly allowed for the rewrite to succeed.
Initially, we experimented with other potential solutions, such as adding a URL rewrite rule directly in the web.config file. However, this approach led to additional errors, indicating that certain server variables weren’t allowed to be set, which ultimately pointed us toward the correct solution.
By leveraging the Application Gateway Host Rewrite Module and adding the applicationHost.xdt file, the issue was resolved. This method provides a robust, reliable solution to the header rewrite problem and ensures seamless integration between the CMS and the rendering engine.
Conclusion: Ensuring a Smooth ASP.NET Core Experience
Setting up the ASP.NET Core rendering engine in conjunction with Sitefinity can significantly improve the performance and scalability of your application. However, as with any complex setup, there are potential pitfalls along the way. In this case, the issue stemmed from Azure’s application gateway and the need for careful configuration of the rewrite rules.
For anyone encountering similar issues, the solution provided here can serve as a guide for resolving header-related errors in Azure App Services. Ensuring the correct configuration of the applicationHost.xdt file and allowing the necessary server variables is a key step toward achieving a smooth, performant ASP.NET Core rendering experience.
At Visus, LLC, we specialize in helping clients navigate and resolve such complex technical challenges, ensuring that their systems work efficiently and effectively across a variety of platforms.