Variables expansion in (HTTP) RequestHeaderModifier

[pzaj2]

I'd love to be able to use variables available in NGINX to modify inbound requests. My use case is fairly straightforward: I'd like to provide a unified header with "request timestamp" to all my applications. While I can't rely on information sent by the client (for hopefully obvious reasons), I surely can rely on information provided by my gateway.

Based on my understanding of the source code, the method that allows variable expansion already exists here.

Theoretically - again, based on my understanding - all it'd take to enable such functionality is using the aforementioned method here.

To the point, my questions are as follows:

• is there something I'm missing in the above?
• are the any reasons behind this limitation?
• last but not least, would you consider accepting a change request as described above that'd allow using variables header modifier filter?

[pleshakov]

Hi @pzaj2

Just to double check, you'd like to do something like below?

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: headers
spec:
  parentRefs:
  - name: gateway
    sectionName: http
  hostnames:
  - "echo.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /headers
    filters:
    - type: RequestHeaderModifier
      requestHeaderModifier:
        set:
        - name: my-request-time
          value: $time_local # https://nginx.org/en/docs/http/ngx_http_core_module.html#var_time_local
    backendRefs:
    - name: headers
      port: 80

[pzaj2]

@pleshakov yes, something like this. I appreciate that this is implementation specific, and that may be the simplest reason why it's disallowed.

But I'll want to do it either way and figured that if I can get this done via the official distribution, everyone could benefit from it, not just me.

[mpstefan]

Hey @pzaj2

I'm going to break this work into a few different issues to tackle. We do need to make a list of what should and shouldn't be allowed in certain contexts for the Gateway API.... but for the first step, did you want to try to implement this for a list of allowed variables for RequestHeaderModifier, with the only entry in the allowed list being "$request_time" for the time being? I'll post the issues when I create them.

[pzaj2]

@mpstefan Sounds like a plan! I must say though, that I'm going on a road trip on Friday and can't guarantee that I'll be able to do it before coming back (mid June).

I don't expect there are any hard deadlines or expectations for this to be done promptly? If so, I'm more than happy to start working on it as soon as I find some time :)

[mpstefan]

Nope! No hard deadlines although we do check PRs for inactivity over 4 weeks, just to keep things moving. I'll go ahead and assign the issue to you so you can take a look at it when you get back.

Thanks for taking a look! Let us know on the issue or your PR if you need some help.

[mpstefan]

I just realized I didn't attach the issue I created for this. Here's the story for the first pass at this work with acceptance criteria. Thanks again!

#2040