Internal redirect interactions with filters (e.g, header_to_metadata) are confusing or undocumented

[sfc-gh-randerson]

I have an internal redirect setup that works for the redirects, but I am unable to find a way to pass data from the redirect response to the followup (internal) request.

I think this is because http filters are not being processed due to the internal redirect, but I'm extremely confused at this point.

I have a route entry that looks like this:

                {
                    "match": {
                        "path": "/monitoring/queries",
                        "headers": [
                            {
                                "name": ":method",
                                "exactMatch": "GET"
                            }
                        ]
                    },
                    "route": {
                        "cluster": "local",
                        "timeout": "0s",
                        "idleTimeout": "50s",
                        "retryPolicy": {
                            "numRetries": 0
                        },
                        "internalRedirectPolicy": {
                            "maxInternalRedirects": 2,
                            "redirectResponseCodes": [
                                307
                            ],
                            "allowCrossSchemeRedirect": true
                        }
                    },
                    "typedPerFilterConfig": {
                        "type.googleapis.com/envoy.extensions.filters.http.header_to_metadata.v3.Config": {
                            "@type": "type.googleapis.com/envoy.extensions.filters.http.header_to_metadata.v3.Config",
                            "responseRules": [
                                {
                                    "header": "x-snowflake-redirect-count",
                                    "onHeaderPresent": {
                                        "metadataNamespace": "snowflake.md",
                                        "key": "redirectcount",
                                        "type": "NUMBER"
                                    }
                                }
                            ]
                        }
                    },
                    "requestHeadersToAdd": [
                        {
                            "header": {
                                "key": "x-snowflake-redirect-permitted",
                                "value": "true"
                            },
                            "appendAction": "OVERWRITE_IF_EXISTS_OR_ADD"
                        }
                    ]
                },

On the routes I'm redirecting to, I have:

                    "requestHeadersToAdd": [
                        {
                            "header": {
                                "key": "x-snowflake-redirect-count",
                                "value": "%DYNAMIC_METADATA(snowflake.md:redirectcount)%"
                            },
                            "appendAction": "OVERWRITE_IF_EXISTS_OR_ADD"
                        },

In addition, I have some Lua that runs as the default Lua configured on the listener:

function envoy_on_response(response_handle)
  local redirect_count = response_handle:headers():get("x-snowflake-redirect-count") or ""
  response_handle:logWarn("redir count = " .. redirect_count)
  local mdcount = response_handle:metadata():get("snowflake.md:redirectcount") or ""
  response_handle:logWarn("metadata redir count = " .. mdcount)
  local smdcount = response_handle:streamInfo():dynamicMetadata():get("snowflake.md:redirectcount") or ""
  response_handle:logWarn("strema metadata redir count = " .. smdcount)
end

This always logs empty strings and notably, doesn't log at all after the 307 redirect response, and seems to only trigger after "final" responses.

Is there some way to pass this data from the internal redirect response to the new internal redirect target?

(The way internal redirects interact with filters and other things isn't really documented as far as I can tell.)

Running 1.26.5 in production and 1.27.0 for local testing. (I should update that one.) Though other upgrades are possible if it'll help make this work.

I can try to pull together a more complete config if that would help, but I think this covers all the relevant details.

Aside: It would really be nice if the header_to_metadata filter would log something with --log-level=trace; it's very opaque right now.

[alyssawilk]

for the logging, feel free to send a PR with logging added and send it my way

For the way internal redirects work, ideally if you start with example.com/bar and redirect to example.com/foo, a new (internal) stream is created and it's as if the client sent the request to example.com/foo so the new stream will only go through foo filters. Any changes made to headers while processing bar filters will be maintained.

[sfc-gh-randerson]

What filters does the response (the 3xx that triggers the internal redirect) go through?

(It doesn't seem to be triggering the header_to_metdata response_rules actions, for example.)

[sfc-gh-randerson]

I read more closely; does this new internal stream copy over the metadata from the original stream?

[sfc-gh-randerson]

Oh, I think you've actually answered my question back in #16777

It seems like there's no way (at the moment) of passing information between the 3xx internal redirect response and the subsequent request. Is that still true?
(I'm going to make some people very sad tomorrow, I think.)

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[sfc-gh-randerson]

Still working on the PR above.

no stalebot