String functions in CEL expressions in responseOverride

[towolf]

Description:
We would like to use this expression to escape & in the Location header that we set to redirect to a login page

%CEL(request.path.replace("&", "%%26"))%

  responseOverride:
  - match:
      statusCodes:
      - type: Value
        value: 401
    response:
      header:
        set:
        - name: Location
          value: https://example.dev/oidc/login?rd="%REQ(:scheme)%://%REQ(:authority)%%CEL(request.path.replace("&", "%%26"))%"
      statusCode: 302

But the Envoy proxy logs this:
failed to create an expression: No overload found in reference resolve step for replace

[optional Relevant Links:]
I found this PR, which sounds like it added string function to CEL expressions, but maybe not in this context?

envoyproxy/envoy#40510

[zirain]

this's something envoy doesn't support.
cc @wbpcode

[wbpcode]

Could you use the header_mutation filter to modify the response headers which will support the extended CEL in the latest version? See envoyproxy/envoy#45815

[zirain]

@wbpcode can we have a global options to enable CEL extensions, maybe in bootstrap?
So we didn't need to enabled this every filters/policies.

[kamalmarhubi]

@zirain I wondered about adding that, but thought it might be harder to sell since it can result in every CEL formatter being opted into the DoS-able allocating string functions. By comparison, keeping opt-in to the formatters that need it felt less controversial. If @wbpcode thinks a global setting for the built-in CEL formatter makes sense, I can look at that too while I'm in this general area.

[towolf]

If there are controversial aspects to this feature request, an alternative for me would also be the possibility to URL encode QUERY_PARAMS. I can unescape, but I cannot escape.

But that's a completely different issue...

[kamalmarhubi]

No idea if it'd actually be controversial to set globally, but I really wanted something that would have a good chance to land in 1.39 so I was conservative.

[zirain]

No idea if it'd actually be controversial to set globally, but I really wanted something that would have a good chance to land in 1.39 so I was conservative.

without a globally, you need to set the config everywhere CEL is supported you need(e.g. accesslog, rbac, tracing).