Cannot iterate on headers from kong.service.response.get_headers()

[mfeledyn]

Is there an existing issue for this?

• I have searched the existing issues

Kong version ($ kong version)

3.4.0

Current Behavior

Trying to iterate over kong.service.response headers which should be a table. I cannot iterate on the object returned by kong.service.response.get_headers()

Expected Behavior

I expected to be able to iterate on the object returned by kong.service.response.get_headers() to traverse all headers.

Steps To Reproduce

Make a test Lua plugin for Kong.
For response() function of the test plugin, here is the code I use:

function _M:response(config)
    kong.log.info(log_prefix().." - INSPECT(kong.service.response.get_headers())="..inspect(kong.service.response.get_headers()))
    # gives {  <metatable> = {    __index = <function 1>  } }  - I expected a table of headers

    kong.log.info(log_prefix().." - INSPECT(#kong.service.response.get_headers())="..inspect(#kong.service.response.get_headers()))
    # gives 0 - I expected the headers count

    kong.log.info(log_prefix().." - INSPECT(kong.service.response.get_headers()[\"Server\"])="..inspect(kong.service.response.get_headers()["Server"]))
    # gives "My GO test server" - Works as expected

    # The 2 "for" loops below try to log all headers, but do not log anything
    for k, v in pairs(kong.service.response.get_headers()) do
      kong.log.info(log_prefix().."header: key="..k..", value="..json.encode(v))
    end
    for k, v in ipairs(kong.service.response.get_headers()) do
      kong.log.info(log_prefix().."header: key="..k..", value="..json.encode(v))
    end
end

In summary I can access a service.response header if I know its name. I cannot iterate over headers, nor know headers count.

Anything else?

No response

[StarlightIbuki]

We're using metatable to handle name aliases (underscore vs. hyphen, upper vs. lowercase characters) and max headers limitation, thus you find an empty table with inspect().
It's possible to support ipairs/pairs and # with some modification to the metatable implementation. Also, maybe we could introduce a parameter or another API to allow fetching raw headers without this processing.
We will be discussing this. Ideas are welcomed.

[hanshuebner]

Created internal ticket KAG-2602

[github-actions]

This issue is marked as stale because it has been open for 14 days with no activity.

[mfeledyn]

Hello !
I don't have a JIRA account and cannot access the ticket. Hope this is ongoing to resolution :-)
Also this thread is now stale so I hope it won't be forgotten.
Cheers!

[StarlightIbuki]

@mfeledyn Hi. Thanks for caring. We maintain an internal task track system and that system is not open. We've created the ticket but no conclusion has been made yet. I'm confirming if this can be scheduled recently.

[StarlightIbuki]

I did a little bit of research on this and noticed that this is not a very trivial problem. Referer: openresty/lua-nginx-module#1595

I've created a fix, but it also changes some of the behavior.

[StarlightIbuki]

As it's not very clear how this should be resolved, I'd like to doc the current behavior and leave it for now.
If possible, could you share the use case of this? So we can evaluate and see if some workaround could be applied.

[mfeledyn]

As it's not very clear how this should be resolved, I'd like to doc the current behavior and leave it for now. If possible, could you share the use case of this? So we can evaluate and see if some workaround could be applied.

Thx for your feed-back on this.

The use case is to trace the headers sent in service's response. The work around I found is to use kong.response.get_headers() in a very high priority plugin so it gets the headers before any other plugin can modify them.

For now I consider it's not only a documentation problem, because the kong.service.response.get_headers() name is simply misleading. This function should be removed and documented as missing.

[StarlightIbuki]

The use case is to trace the headers sent in service's response. The work around I found is to use kong.response.get_headers() in a very high priority plugin so it gets the headers before any other plugin can modify them.

Glad to know a workaround works for you.

For now I consider it's not only a documentation problem, because the kong.service.response.get_headers() name is simply misleading. This function should be removed and documented as missing.

I agree. The current behavior is not logical (the API does not function as designed) and it should be eventually fixed. However, it is not a top priority at the moment and a resolution is not planned in the foreseeable future.

We welcome community PRs. If you are interested, we could use PR #11708 as a starting point for your involvement. Also, please be assured that there is no pressure to contribute.