I’m using the kong ingress in my kubernetes cluster. Here is a part of my yaml:
- path: /api
- path: /
My problem is when my front-end is uploading a file to my api.
It uses the endpoint
/api/uploadfile but kong is stripping the path to
/uploadfile. Then my api respond to the front-end with a Location header to tell the front-end where to send the file parts. This header is equal to
https://mydomaine.com/uploadfile, it is missing the
/api as the api app doesn’t know about this part of the url.
What I need is Kong to rewrite this header to add the
I made a little uml diagram to explain better what I need.
I looked at the response-transformer plugin but could not find a way to use it in my use case.
I also tried to use this annotation on my yaml:
But it did not change anything.
I’m a little bit lost here so if someone could help me it would be appreciated.
Version: kong:2.0 (Docker)
What if you split this ingress into two: one for /api (without path stripping) and one for /web with path stripping?
I’m happy with the path stripping for the api. It’s actually the only one that use it.
If I don’t strip it it means that my api knows that it needs to be behind /api to work and I would like to keep this responsability within the ingress if possible.
This can often be handled at the upstream application level: many applications have settings to indicate that they’re behind a proxy and that they need to prepend some root URL to their redirects and similar.
At the Kong level you’d probably want to use a serverless plugin in the header_filter phase to modify the existing Location header. response-transformer can modify the entirety of a header, but it can’t modify part, e.g. by prepending a string onto a header value as you want here.
At FactSet, we wrote a plugin we call location-rewrite-response-modifier, which basically patches the location header if it’s a relative path, or if it’s an absolute path and the upstream host, and path prefix, match the location header. Probably don’t have time to work through open sourcing it, but the general pseudo-code is:
- foreach location header
- if the location header isn’t relative, or the host doesn’t match the upstream host, keep the location header
- if the location header path doesn’t match the upstream path prefix, keep the location header
- if the route path prefix and upstream path prefix match, keep the location header
- remove the old location header, strip the upstream path prefix, prepend the route path prefix, and substitute the upstream host with the route host, then readd the location header
Something like that. Hope that helps.