Kong / kong

🦍 The Cloud-Native API Gateway and AI Gateway.
https://konghq.com/install/
Apache License 2.0
39.33k stars 4.82k forks source link

Request Transformer will not touch certain headers. #2889

Closed simonpie closed 7 years ago

simonpie commented 7 years ago

NOTE: GitHub issues are reserved for bug reports only.

Please read the CONTRIBUTING.md guidelines to learn on which channels you can seek for help and ask general questions:

https://github.com/Mashape/kong/blob/master/CONTRIBUTING.md#where-to-seek-for-help

Summary

Behaviour of Kong changed between 0.10 and 0.11. Now, the x-forwarded-host will be set to the original host in the original uri and cannot be removed even using the request transformer.

Steps To Reproduce

Publish an api and have kong be fronted by a reverse proxy, then look at what the upstream for the api receives.

One can simulate this by having two apis : 1) First api: A, with uri /test and upstream localhost:8000/testupstream 2) Second api: B, with uri /testupstream and use the terminating plugin.

When you look at the log of the second api, you can see that x-forwared-host will be the host name in the uri of the first api. For example, if I call api.mycompany.org:8000/test I will have the x-forwared-for in the second api set to api.mycompany.org

Additional Details & Logs

stack traceback: [C]: in function 'error' /usr/local/share/lua/5.1/kong/cmd/start.lua:62: in function 'cmd_exec' /usr/local/share/lua/5.1/kong/cmd/init.lua:88: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:88> [C]: in function 'xpcall' /usr/local/share/lua/5.1/kong/cmd/init.lua:88: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:45> /usr/local/bin/kong:7: in function 'file_gen' init_worker_by_lua:38: in function [C]: in function 'xpcall' init_worker_by_lua:45: in function '''

thibaultcha commented 7 years ago

Yes, the behavior between 0.10 and 0.11 indeed changed regarding the X-Forwarded-* headers, as noted in the release notes.

The X-Forwarded-* headers are now implemented as per their standard interpretation, instead of carrying Kong-specific information. The behavior you are seeing seems to be the one we intend to provide for Kong users. We do have plans to add X-Kong-Matched-* headers, that would carry upstream information about how a given requested was matched and proxied (such headers would have to be configurable, or provided by a plugin because we do not wish to include them by default).