New X-Forwarded-Prefix headers should contain route path only #6190
Comments
|
@jerfer do you know of an authoritative source for this header's behavior, or absent that, any source that describes this header's behavior? We should probably be able to learn more about it by reviewing the source of other proxies, but it'd be useful to know if there is something close to an authoritative source. |
|
@rainest Here you go, I found one of each.
Does that work for you? |
|
This is duplicate of #6132 |
bungle
added a commit
that referenced
this issue
Aug 7, 2020
…warded_prefix ### Summary The PR #5620 implemented `X-Forwarded-Prefix` wrong as reported in these: - #6190 - Kong/kubernetes-ingress-controller#784 - #6132 And also by some other sources. This commit re-implements `X-Forwarded-Prefix`: 1. Is there trusted `X-Forwarded-Prefix` header in request? If yes, then set that as the `X-Forwarded-Prefix` (note: at this point we don't support multi-value `X-Forwarded-Prefix` headers, e.g. appending. We don't support multi-value in `X-Forwarded-Host/-Port/-Proto` either. 2. Has Kong router stripped the prefix of the request URI before proxying, if yes, then set `X-Forwarded-Prefix` to match the stripped prefix. 3. If 1 or 2 didn't set the header, set it to `/`. ### Issues Resolved Fix #6190 Fix Kong/kubernetes-ingress-controller#784 Fix #6132
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
See #5620 and specifically https://github.com/Kong/kong/pull/5620/files#diff-8cb7654e2e5f4b45e64e3cd2afdcfcd9R239-R271 for current behavior.
Based on the report in Kong/kubernetes-ingress-controller#784 and a brief reading of that code, Kong will either send an existing
X-Forwarded-Prefixheader from a trusted sender or will generate a newX-Forwarded-Prefixheader containing the entire path.Though unclear, I believe the headers that Kong generates itself should contain the route path only, i.e. run https://docs.konghq.com/2.1.x/pdk/kong.router/#kongrouterget_route, extract the path, and set
X-Forwarded-Prefixto that.Steps To Reproduce
X-Forwarded-Prefixheader received upstreamAdditional Details & Logs
From the original report, CE 2.0.4 running on EKS 1.17. Exact route config used is available in Kong/kubernetes-ingress-controller#784 but I believe this should affect any route equally; exact config shouldn't matter.
The correct behavior here is unclear. Based on the header name alone, I agree with the controller report: this should send the Kong route path prefix only, or the portion of the request matching it in the case of regex paths. However, this header is non-standard, and I cannot find anything that appears to be an authoritative source on its behavior. There are several open questions:
X-Forwarded-Prefixheader from a trusted downstream, should we combine it with our route prefix in any way? As-is we use the downstream value exclusively.The text was updated successfully, but these errors were encountered: