Trailing slash removed from root requests

[stevecookform3]

Given the example swagger:

swagger: '2.0'
basePath: "/myservice"
paths:
  /:
    get:

the following code in request.go doesnt create the correct path:

	// create http request
	var reinstateSlash bool
	if r.pathPattern != "" && r.pathPattern != "/" && r.pathPattern[len(r.pathPattern)-1] == '/' {
		reinstateSlash = true
	}
	urlPath := path.Join(basePath, r.pathPattern)
	for k, v := range r.pathParams {
		urlPath = strings.Replace(urlPath, "{"+k+"}", url.PathEscape(v), -1)
	}
	if reinstateSlash {
		urlPath = urlPath + "/"
	}

So in this example:

• r.pathPatterm is "/"
• basePath is "/myservice"

request.buildHTTP currently bins off the trailing slash to set the urlPath to: "/myservice" instead of the correct "/myservice/". Changing basePath to "/myservice/" doesnt make any difference.

Couple of options:

1. Remove && r.pathPattern != "/" - not sure what this is trying to achieve
2. Swap out path.Join for something that is URL aware (e.g. as suggested by https://stackoverflow.com/questions/34668012/combine-url-paths-with-path-join)

[stevecookform3]

This seems to be the commit that introduced the change: de2e648

however I dont see any specific test cases that relate to the root path.

@casualjim @e-zhang - do you know what the expected behaviour is with the case above? Any issue with just removing the r.pathPattern != "/" from the expression?

[e-zhang]

I think the original change was introduced in 20675b2

It looks like that change was for the case where basePath == "".

Here's the difference in behavior from path.Join in a playground.

[casualjim]

there is nothing in the spec that says a trailing / is significant.
Servers sometimes choose to implement one or the other and not both.
If you depend on this behavior it might be better to reconsider the server you're using because url normalizers often just remove insignificant chars.

[stevecookform3]

@casualjim unfortunately this is a third-party service, so we cant change their implementation. Like you say, its not clear from the spec how to deal with this case, so i'll probably open a ticket over there.

I did find a workaround though, if you specify the endpoint like this:

paths:
  //:
    get:

then it resolves to the intended destination /myservice/

[casualjim]

we could add a method to the runtime that allows you to hook into or augment the path normalization?