x-forwarded-proto: https added to HTTP inter-service calls by app name

[CezaryKlus]

This issue is a:

• bug report

Issue description

Calling from inside of the custom Vnet-integrated internal ACA environment:

curl **http**://api

On the api side in logs I find

Request starting HTTP/1.1 GET **http**://api
...
x-forwarded-proto: **https**
...
Request finished HTTP/1.1 GET **https:**//

This e.g. breaks internal IdentityServer calls that emit the https:// issuer instead of http://

Ingress configuration:

"ingress": {
    "external": false,
    "targetPort": 8080,
    "transport": "Auto",
    "traffic": [
        {
            "weight": 100,
            "latestRevision": true
        }
    ],
    "allowInsecure": true,
},

UseForwardedHeaders() is being used in our Apps.

Expected behavior
x-forwarded-proto equals to http when the request is HTTP

Actual behavior
x-forwarded-proto equals to https when the request is HTTP

[Tratcher]

I was able to repro this and see where the confusion is coming from.

Short names like api are routed through the envoy sidecar container, which then uses https to communicate with the main envoy instance. That intermediate https is what causes envoy to add x-forwarded-proto: https.

Workaround: use the FQDN to bypass the envoy sidecar and communicate directly with the main envoy instance using http.
http://api.internal.kindwater-1f6ab775.azurecontainerapps.io.

We'll consider if there are other ways to enable this scenario in the future.

[CezaryKlus]

Unfortunately, our solution heavily relies on simple names for inter-service calls. We resorted to a workaround to set the dynamically resolved URLs to fixed ones.