Trailing slash added at the end of upstream_url ? Can we remove it ?

[JnMik]

Hello Guys

When I use strip_request_path parameter, seems Kong / Nginx always add a trailing slash at the end of my upstream_url.

Is there any way I can get rid of it ?

Steps to reproduce :

curl -X POST --url http://localhost:8001/apis/ --data 'name=test-trailing-slash-api' --data 'upstream_url=http://www.mockbin.com/bin/ea0bfc2e-e490-4bdb-bcb4-548f57feebd7' --data 'request_path=/test-trailing-slash' --data 'strip_request_path=true' | jq

Answer would be :
{
"upstream_url": "http://www.mockbin.com/bin/ea0bfc2e-e490-4bdb-bcb4-548f57feebd7",
"request_path": "/test-trailing-slash",
"id": "4d393d19-4eb0-4b43-cb4f-f39fe59ceaf9",
"created_at": 1446472365000,
"strip_request_path": true,
"name": "test-trailing-slash-api"
}

Note that there is no trailing slash on the upstream_url in the response.

Now run a curl to see the result in mockbin :

curl -X GET --url "http://localhost:8000/test-trailing-slash?test"

Result in mockbin with a trailing slash :
. . .
"method": "GET",
"url": "http://www.mockbin.com/bin/ea0bfc2e-e490-4bdb-bcb4-548f57feebd7/?test",
. . .

[thibaultcha]

Thanks for reporting btw. Will try to tackle this when I have some time.

[JnMik]

Happy to help :)

Le jeudi 5 novembre 2015, Thibault Charbonnier notifications@github.com a
écrit :

Thanks for reporting btw. Will try to tackle this when I have some time.

—
Reply to this email directly or view it on GitHub
#675 (comment).

[subnetmarco]

@JnMik, the PR I just referenced should fix this problem

[JnMik]

Hey that's awesome !
Thx for the great job

I'll give it a try when I'm back at the office :)

[subnetmarco]

This will be available in the next version.

[marcelmfs]

This changes breaks RFC 3986 which states that a URI referenced without a leading forward slash should be treated as relative: #715

[subnetmarco]

@marcelmfs this issue was about the the last slash in the URI, not the leading slash. Can you send me an example to reproduce your issue?

[marcelmfs]

I'll first describe the user case I'm trying to replace.

We're currently using static nginx location directives for a set of microservices and apps, in the form of:

location /login/ {
   proxy_pass https://login_app;
}

location /api/sso/ {
  proxy_pass https://sso_service;
}

In nginx documentation, there is a distinctive section regarding the trailing slash on the location pattern {} directive (ref: http://nginx.org/en/docs/http/ngx_http_core_module.html#location):

If a location is defined by a prefix string that ends with the slash character, and 
requests are processed by one of proxy_pass, fastcgi_pass, uwsgi_pass, 
scgi_pass, or memcached_pass, then the special processing is performed. In 
response to a request with URI equal to this string, but without the trailing slash, 
a permanent redirect with the code 301 will be returned to the requested URI 
with the slash appended. If this is not desired, an exact match of the URI and 
location could be defined like this:

location /user/ {
    proxy_pass http://user.example.com;
}

location = /user {
    proxy_pass http://login.example.com;
}

By removing the trailing slash on location directives without taking that into account, kong breaks this compatibility where a location that's not a folder and for which a proxy_pass should occur is not treating relative href accordingly. Because, my first location directive:

location /login/ {
  proxy_pass https://login_app;
}

is being rewritten as /login and therefore, all hrefs in the html are now relative to the root_url, instead of being relative to /login/main.css for example. I think this breaks the protocol in the mentioned RFC.

That's why I can't use the latest version of kong anymore and had to switch to a custom lua module.

[subnetmarco]

@marcelmfs I will try to explain below the change introduced by the PR that closed this issue, so that we can be on the same page and I can better understand what's breaking your API.

The PR makes the proxied path consistent to the path requested by the client. Specifically, let's consider the following API on Kong:

request_path=/test 
strip_request_path=true 
upstream_url=http://api.com/service

Then the following incoming requests will be proxied to:

• kong:8000/test/get -> http://api.com/service/get
• kong:8000/test/get/ -> http://api.com/service/get/

Without unexpectedly adding a final slash when the original request didn't have it. Previously instead the behavior was:

• kong:8000/test/get -> http://api.com/service/get/

Which is more unexpected, since the original request had no final slash.

[marcelmfs]

Yes, that's the way to go. Don't change default behaviour of nginx as it does things under the hood that might break how people expect it to work.

[alexraju91]

Is this change released yet? I'm still getting this issue.

Created API using
$ curl -i -X POST --url http://localhost:8001/apis/ --data 'name=test' --data 'upstream_url=http://xx.xx.xx.xx/api/test' --data 'request_host=xxxxxxx'

curl -i -X GET --url http://localhost:8000/ --header 'Host: xxxxxxx'
The request was forwarded to http://xx.xx.xx.xx/api/test/ (Added a trailing slash automatically)

[marcelmfs]

The request path was GET /, so is nginx who's adding the trailing slash. You app should act accordingly, if test is an HTML and not a endpoint, it should be stated so.

[alexraju91]

@marcelmfs
test is not an HTML and its the endpoint.
The route in my application is defined like this.
I didn't get what you meant by The request path was GET /. Please elaborate.

[subnetmarco]

@alexraju in your example you are using request_host resolver and not a path resolver. When you are requesting GET /, Kong will append the requested endpoint to the upstream_url, hence http://xx.xx.xx.xx/api/test/.

To extend your example, if you were requesting GET /another_endpoint then the final URL requested would be http://xx.xx.xx.xx/api/test/another_endpoint (not http://xx.xx.xx.xx/api/testanother_endpoint).

The original problem in this issue was an edge-case in request_path resolvers with strip_request_path=true, which doesn't apply in your case.

[fysheets]

Hi I realize this was fixed a long time ago, but when the above comment said that this would be updated in the "next version" which version # did this fix actually go out in? Trying to debug a system and I want to validate the versioning. I couldn't find documentation with the dates that each version was released. Thank you!

[subnetmarco]

Looking at the CHANGELOG, it seems like the "next version" is 0.8.3, released on 2016/06/01.

[fysheets]

Awesome, thanks for the quick reply, info, and the link!