Azure-functions-host: Function Proxy will broken wildcard route when backendUri using IP address

[doggy8088]

Investigative information

• Timestamp: 2017-12-22 PM 03:40 (GMT)
• Function App version (1.0 or 2.0-beta): N/A
• Function App name: will-func
• Function name(s) (as appropriate): N/A
• Invocation ID: N/A
• Region: Central US

Repro steps

Provide the steps required to reproduce the problem:

1. Create a Function Proxy.
2. Define proxies.json as below. Please just use the exact proxies.json content to test. Test the http://211.21.154.7/{all} exactly. You will see the problem. It's really weird. Only few IPs (not all) can reproduce this problem!

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "root": {
            "matchCondition": {
                "route": "/{*all}"
            },
            "backendUri": "http://211.21.154.7/{all}"
        }
    }
}

Expected behavior

• After I perform step 2, the function proxy should browser the whole website normally.

Actual behavior

• After I perform step 2, the function proxy only route requests to the backendUri and UrlEncoded all the slashes. Here is the log I found in my Apache web server.

52.165.163.74 - - [24/Dec/2017:09:04:42 +0800] "GET /admin%2Fxet_user_login.php HTTP/1.1" 404 457 "-" "Mozilla/5.0,(Windows NT 10.0; Win64; x64),AppleWebKit/537.36,(KHTML, like Gecko),Chrome/63.0.3239.108,Safari/537.36"

Known workarounds

• Define each level of the URL segements just like below:

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "root": {
            "matchCondition": {
                "route": "/{*all}"
            },
            "backendUri": "http://211.21.154.7/{all}"
        },
        "second": {
            "matchCondition": {
                "route": "/{level1}/{*all}"
            },
            "backendUri": "http://211.21.154.7/{level1}/{all}"
        },
        "third": {
            "matchCondition": {
                "route": "/{level1}/{level2}/{*all}"
            },
            "backendUri": "http://211.21.154.7/{level1}/{level2}/{all}"
        },
        "forth": {
            "matchCondition": {
                "route": "/{level1}/{level2}/{level3}/{*all}"
            },
            "backendUri": "http://211.21.154.7/{level1}/{level2}/{level3}/{all}"
        }
    }
}

Related information

References:

• Work with proxies in Azure Functions | Microsoft Docs
• Using Azure Functions Proxies – Jaspers' Weblog

[doggy8088]

@omkarmore83
After two days research, I finally realize the real problem! It's not about the IP address as the domain name in the backendUri. It's the url segements in the backendUri been UrlEncoded by Azure Function Proxy. For example:

If the proxies.json setting below:

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "root": {
            "matchCondition": {
                "route": "/{*all}"
            },
            "backendUri": "http://some.domain/{all}"
        }
    }
}

When you request to http://yourfunc.azurewebsites.com/Home/About, the Function Proxy will translated the URL into http://some.domain/Home%2FAbout. If the backend server is IIS, there is not a problem at all, because IIS can treat encoded slash as a normal slash. When you're using Apache Web Server, it's gonna failed because the AllowEncodedSlashes configuration is default Off which means unable to treat encoded slash normally.

Due to one of my website is created by ASP.NET Core and hosted inside the Linux container and deployed on Kubernetes. So my website is run on native Kestrel web server. Kestrel doesn not support "encoded slash" in the url path, so that the proxy requests from Function Proxies will become HTTP 404 Not Found. That's the real problem I met.

So here are the suggestions to Funcion Proxy team.

1. If the route variable used in the backendUri's "Path" part, please use UrlPathEncode.
2. If the route variable used in the backendUri's "QueryString" part, please use UrlEncode.

[doggy8088]

@omkarmore83 @safihamid Do you have time to take a look on this issue? Did you confirmed that this is a problem?

[safihamid]

@doggy8088 The current plan is to address this in Functions V2(Beta) as it might break existing customers on V1. Would this work for you?

[doggy8088]

@safihamid That works for me. Thanks.

[safihamid]

Ok great! i will update this thread when the fix is out. it will most likely be a month or two out.

[doggy8088]

@christopheranderson @safihamid Does this problem been solved in any alpha/beta release of the Azure Function Runtime?

[safihamid]

Unfortunately not yet.

[safihamid]

PR here: https://github.com/Azure/azure-functions-host/pull/2732

[doggy8088]

@safihamid Is this PR already deployed to Azure? What can I expected now?

[safihamid]

@doggy8088 the fix is checked in for V2 but not deployed yet. it should be out in the next few weeks. will keep this thread updated when deployed.

[safihamid]

This is now deployed for V2 and the fix is also checked in for V1 and will be deployed with the next runtime release of V1.
The default behavior hasn't changed. And if you need the new behavior you will need to add this app setting to your function app:
AZURE_FUNCTION_PROXY_BACKEND_URL_DECODE_SLASHES : true