I ‘m presently using Azure ‘s Application Gateway with a backend pool use Azure ‘s App Service. When the application gateway forwards your request to the backpool, it besides forwards X-Original-Host HTTP Header together with it to help you identity which listener the gateway primitively acted upon but what if you wanted it to match the HOST header at the web server ( app service ) ? This might be useful for cases where you need to generate absolute URLs in your web app for whatever reason be it sitemaps or some syndication feed etc. Since we are using Azure ‘s App service, we do n’t have american samoa much control over IIS as we are used to but fortunately for us Azure has provided us with a way to transform the applicationHost.config via transforms. On the Azure Portal head over to your app serve then jump over to the Kudu > Debug console > CMD and create a file mention applicationHost.xdt under d:\home\site directory which allows you set the allow server variables for IIS by overriding/transforming the applicationHost.config file applicationHost.xdt



  
    
      
        
        
      
    
  

then on Web.config file within d:\home\site\wwwroot you ‘ll need a new convention which basically sets the HTTP_HOST server varying to be {HTTP_X_ORIGINAL_HOST} ( surrounding curly couple means to evaluate ) on the stipulate that the respect of the hypertext transfer protocol header X-Original-Host is NOT empty ( e.g. ^$ ).

X-Original-Host is a HTTP header which Azure ‘s Application Gateway forwards to its backend pools Web.config

 
  
    
      
        
          
          
            
          
          
              
          
        
            
     
  

IMPORTANT : once the two changes are made, we will need to restart BOTH the SCM locate ( via the Restart Site button on { foo } .scm.azurewebsites.net/SiteExtensions ) and besides the web site itself ( Via the Azure Portal, CLI or Powershell ) or the changes wo n’t kick in. And to test whether the right headers are being transformed, plainly add some debugging code in your hypertext markup language ( or razor page in my case of ASP.NET MVC ) Index.cshtml

HTTP_HOST : @ Request.ServerVariables [ `` HTTP_HOST '' ] HTTP_X_ORIGINAL_HOST : @ Request.ServerVariables [ `` HTTP_X_ORIGINAL_HOST '' ]
X-Forwarded-For : @ Request.Headers [ `` X-Forwarded-For '' ] X-Forwarded-Proto : @ Request.Headers [ `` X-Forwarded-Proto '' ] X-Original-Host : @ Request.Headers [ `` X-Original-Host '' ]

Side note for deployments outside of App Service

If we have greater control over the host environment, possibly using App Service for Windows Containers ( in Public preview at time of writing ) the lapp could be achieved using powershell with Set-WebConfigurationProperty cmdlet in your Dockerfile while building your image. The below model assumes you ‘ve built your image using the Default Web Site but can obviously be changed to however your web site is configured .

Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -location 'Default Web Site' ` 
-filter 'system.webServer/rewrite/allowedServerVariables' -Name '.'  `
-value ( @{ name = 'HTTP_HOST' }, @{ name = 'HTTP_X_ORIGINAL_HOST' } )

Which would produce applicationHost.config


    
            
                
                    
                        
                        
                    
                
                
            
    

here is the Dockerfile for completeness
Dockerfile


ARG LTSC_VERSION=ltsc2016
FROM mcr.microsoft.com/dotnet/framework/aspnet:4.7.2-windowsservercore-${LTSC_VERSION}

RUN iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
RUN choco install urlrewrite -y

WORKDIR /inetpub/wwwroot 

RUN Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -location 'Default Web Site' -filter 'system.webServer/rewrite/allowedServerVariables' -Name '.'  -value ( @{ name = 'HTTP_HOST' }, @{ name = 'HTTP_X_ORIGINAL_HOST' } )

ARG PUBLISH_DIR
ADD output/${PUBLISH_DIR}/. ./

References

hypertext transfer protocol : //github.com/projectkudu/kudu/wiki/Azure-Site-Extensions # understanding-what-could-go-wrong-with-xdt-transforms

beginning : https://themedipia.com
Category : Website hosting

Leave a Reply

Your email address will not be published.