feat: As a user, I want to use Nginx variables in proxy-rewrite.regex_uri

[mikyll]

Description

Currently, proxy-rewrite supports NGINX variable resolution in uri config parameter, but not in regex_uri. See APISIX Docs | Plugins - proxy-rewrite for reference.

Examples:

• 🟢 Nginx variable resolution in uri:

  proxy-rewrite:
    uri: /api/$arg_name

• 🟢 Pattern variable resolution in regex_uri:

  proxy-rewrite:
    regex_uri:
      - ^/api/(.*)/users/(.*)$
      - /v2/$1/external-users/$2

• 🔴 Nginx variable resolution in regex_uri:

  proxy-rewrite:
    regex_uri:
      - ^/api/(.*)/users/(.*)$
      - /v2/$1/external-users/$arg_name

  This is not allowed and will throw an error.

Question

Since regex_uri already supports variables resolution for regex patterns (e.g. patterns matched by (.*)/(.*) can be referenced with $1 and $2), I was wondering: why does uri allow Nginx variables resolution, but regex_uri does not? Is this a design choice? Are there any contraindications in implementing this feature?

[Baoyuantop]

Technically, this is feasible. Could you describe the specific use case?

[mikyll]

@Baoyuantop

Personal Use Case

My specific use case is somewhat similar to the one described in #13132: we have a route that points to an external provider, which is configured to append an apikey in the query string via proxy-rewrite plugin (e.g. /api/users/:user_id/ -> /api/users/:user_id/?apikey=foobar123).

I'd like to fetch the API key with another plugin (or via serverless-pre-function), inject it in a context variable, e.g. ctx.var.apikey and then retrieve it in proxy-rewrite.

Pseudo-code example:

uri: /api/users/:user_id
plugins:
  serverless-pre-function:
    phase: rewrite
    functions:
      - |
        return function(_, ctx)
          ctx.var.myapikey = fetch_secrets(ctx.var, true) -- Or some other logic to fetch the secret
        end
  proxy-rewrite:
    host: external-host
    regex_uri:
      - ^/api/users/(.*)$
      - /v2/api/users/$1/?apikey=$myapikey

Moreover, since the route also uses path parameters (user_id -> $1), we cannot use .uri and must use .regex_uri.

Of course even with this feature, the upstream URI with the injected secret would still be logged, but at least the configuration is "safer".

Considerations

I understand this would be a free "positive side-effect" of the feature, and not the main intended behaviour 🙂
However, the main point I'd like to address is that, to me, it just makes sense because .uri already supports it, and .regex_uri should be a an extension to what .uri can do 👀

That's also why I was wondering if that could introduce any unknown/negative side-effect, because maybe it was implemented this way for a specific design choice 🙂

I can propose a PR if you think this feature would be useful