Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to add X-Kong-Upstream-Status header to response #47

Open
sec23206 opened this issue Sep 4, 2021 · 4 comments
Open

How to add X-Kong-Upstream-Status header to response #47

sec23206 opened this issue Sep 4, 2021 · 4 comments
Labels
pending author feedback Waiting for feeback from author

Comments

@sec23206
Copy link

sec23206 commented Sep 4, 2021

Trying to understand using the JavaScript PDK and I've written a simple plugin which converts XML from a legacy web service to JSON. It seems to be working for the most part, but I'm seeing a message in the Kong logs after the plugin executes:

2021/09/04 09:23:31 [error] 34#0: *66 [lua] handler.lua:1487: before(): failed to set X-Kong-Upstream-Status header while sending to client, client: 172.21.0.1, server: kong, request: "POST /vsedws/FindUser HTTP/1.1", host: "localhost:8000"

I've noted that the other X-Kong-* headers like X-Kong-Upstream-Latency and X-Kong-Proxy-Latency are still passing thru to the client, but not X-Kong-Upstream-Status. I've tried adding it myself in the response(kong) method:

kong.response.addHeader("X-Kong-Upstream-Status", await kong.service.response.getStatus());

But this doesn't seem to work. I can add other headers, e.g.:

kong.response.addHeader("foo", "bar");

I was even able to add it if I change the name to "Kong-Upstream-Status" and also added a header called "X-Kong-foo", so it seems that it's the fact that it's X-Kong-Upstream-Status. Also, don't understand why other X-Kong-* headers seem to be passing thru unmolested, but this one is stripped out by the existence of this plugin.

Is that just a limitation of the PDK, or am I missing something?

@sec23206
Copy link
Author

sec23206 commented Sep 4, 2021

Actually, I just tried something which had an effect ... in the startup for Kong, we include this setting:

-e "KONG_HEADERS=X-Kong-Proxy-Latency, X-Kong-Response-Latency, X-Kong-Upstream-Latency, X-Kong-Upstream-Status, X-Kong-Admin-Latency" \

This is because for security reasons, we want to ensure Kong does not include the "Via" header to clients (so they don't know they are talking to Kong). My understanding about this setting is that it tells Kong which are the "legal" headers to send to a client. When I removed this from the startup, now I'm seeing the X-Kong-Upstream-Status header that my plugin is adding. But I don't understand why the other "legal" headers like X-Kong-Upstream-Latency went through OK, and what is the connection between this setting and a bespoke plugin that tried to set one of the headers.

@fffonion
Copy link
Contributor

@sec23206 In which phase is your plugins setting the header?

@sec23206
Copy link
Author

@sec23206 In which phase is your plugins setting the header?

In the response phase.

@fffonion
Copy link
Contributor

I feel like reponse phase is the reason but haven't verified. Although as it's name suggested, response phase
is not actually what Kong is producing responses. It's more for plugins that requires to do some mutation or inspecting
of the response body. But access may just be too early for your use case. In Lua Kong you can use header_filer but they
are not part of JS PDK.

Could you print the result of await kong.service.response.getStatus() in the same phase?

@hanshuebner hanshuebner added the pending author feedback Waiting for feeback from author label Sep 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pending author feedback Waiting for feeback from author
Projects
None yet
Development

No branches or pull requests

3 participants