Azure Function App - HttpContext IServerVariablesFeature not supported in local environment

Question

I am running an azure function app with runtime 4, .NET 6.0. When I call the function app in a locally running environment the req.HttpContext.GetServerVariable() always returns null because the IServerVariablesFeature is not supported in the list of context.Features.

When I deploy this to an azure hosted instance of the function app, the variables are populated correctly. I have done extensive research and have been unable to find out if this is intentionally not supported or if I am missing some form of additional configuration in my local environment.

Here is a test function that attempts to read 3 different server variables and returns them as a string and can be called using a get request in postman or via a browser http://localhost:7071/api/GetServerVariable:

    public static class TestFunction
    {
        [FunctionName("GetServerVariable")]
        public static async Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "GetServerVariable")] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            var url = req.HttpContext.GetServerVariable("URL");
            var remoteAddr = req.HttpContext.GetServerVariable("REMOTE_ADDR");
            var https = req.HttpContext.GetServerVariable("HTTPS");

            var response = $"Current server variables: URL: {url} - REMOTE_ADDR: {remoteAddr} - HTTPS: {https}";

            log.LogWarning(response);

            return new OkObjectResult(response);
        }
    }

score 0 · Answer 1 · answered Feb 16 '22 at 08:35

According to this document, GetServerVariable returns

null if the server does not support the IServerVariablesFeature feature. May return null or empty if the variable does not exist or is not set.

One of the workaround is to include Forwarded headers Middleware:

Before the request reaches the app, proxy servers, load balancers, and other network appliances usually hide information about the request. The original scheme is lost when HTTPS requests are proxied via HTTP and must be transmitted in a header. The originating client IP address must also be forwarded in a header because an app receives a request from the proxy rather than its true source on the Internet or corporate network.

From the MSDN article:

Although retrieving just the REMOTE_ADDR server variable should be enough, I found resources online that suggested that code like this should also check the HTTP_X_FORWARDED_FOR variable; if the request comes through a proxy server that translates the address, it's this variable that contains the correct address. If you request a server variable that doesn't exist, the ServerVariables property returns an empty string. Therefore, even though this property doesn't appear in my tests, attempting to retrieve its value doesn't cause trouble.

The Forwarded Headers Middleware reads the headers X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Proto and fills in the associated fields on HttpContext.

REFERENCES:- How to access server variables in ASP.Net Core

Azure Function App - HttpContext IServerVariablesFeature not supported in local environment

1 Answers1