Use FnApiUrl.Path when getting server version (fnproject/fn#1339)

[vzDevelopment]

This issue fixes a bug that was preventing the CLI (and any other libraries that use this) from finding the server version when the server was accessed using a non-root path c.f. fnproject/fn#1339.

As you can see, before the change the server version is ? when using a non-root path:

vzarola-Mac:testing vzarola$ echo $FN_API_URL
http://127.0.0.1:8888/fn/
vzarola-Mac:testing vzarola$ fn version
Client version is latest version: 0.5.69
Server version:  ?

This is because the cli was trying request /version as shown by the logs from the reverse proxy I was using:

CONNECT   Apr 04 20:35:16 [85721]: Request (file descriptor 10): GET /version HTTP/1.1

Once I made this change and recompiled the cli the output of the command is now as follows:

vzarola-Mac:testing vzarola$ echo $FN_API_URL
http://127.0.0.1:8888/fn/
vzarola-Mac:testing vzarola$ fn version
Client version is latest version: 0.5.69
Server version:  0.3.687

And the logs from the reverse proxy show it's correctly requesting /fn/version:

CONNECT   Apr 04 20:33:58 [85721]: Request (file descriptor 10): GET /fn/version HTTP/1.1

The cli is also working when no $FN_API_URL is set:

vzarola-Mac:testing vzarola$ unset FN_API_URL
vzarola-Mac:testing vzarola$ fn version
Client version is latest version: 0.5.69
Server version:  0.3.687

And it also works if I start the server on another port try with no path:

vzarola-Mac:testing vzarola$ export FN_API_URL=http://localhost:8081
vzarola-Mac:testing vzarola$ fn version
Client version is latest version: 0.5.69
Server version:  0.3.687

[rdallman]

thanks @vzDevelopment ! have you by chance tested the default when the url.Path is the empty string, does it still default to root correctly and work with the cli like normal? LGTM if both work, just double checking.

[vzDevelopment]

Hi Reed, I'm not sure I fully understand - don't the last two test when the url.Path is an empty string?

However, here's what happens when the API URL is set to the default (i.e. no path is set):

# Server is running on localhost:8080

vzarola-Mac:testing vzarola$ echo $FN_API_URL
http://localhost:8080
vzarola-Mac:testing vzarola$ fn version
Client version is latest version: 0.5.69
Server version:  0.3.687

# Server is running on localhost:8080
# FN_API_URL is not set so the default is taken from code

vzarola-Mac:testing vzarola$ echo $FN_API_URL

vzarola-Mac:testing vzarola$ fn version
Client version is latest version: 0.5.69
Server version:  0.3.687

I was curious to see what would happen if I added a path of /:

# Server is running on localhost:8080

vzarola-Mac:testing vzarola$ echo $FN_API_URL
http://localhost:8080/
vzarola-Mac:testing vzarola$ fn version
Client version is latest version: 0.5.69
Server version:  0.3.687

# Server is running on localhost:8080

vzarola-Mac:testing vzarola$ export FN_API_URL=http://localhost:8080//
vzarola-Mac:testing vzarola$ fn version
Client version is latest version: 0.5.69
Server version:  0.3.687

And a test I did, but looks like I missed it from the PR, was testing a non-default path and port (here the server is running on 8081:

# Server is running on localhost:8081. 
# Reverse proxy is redirecting localhost:8888/fn/ to localhost:8081

vzarola-Mac:testing vzarola$ echo $FN_API_URL
http://localhost:8888/fn/
vzarola-Mac:testing vzarola$ fn version
Client version is latest version: 0.5.69
Server version:  0.3.687

The proxy logs are as follows:

CONNECT   Apr 05 09:31:57 [10548]: Request (file descriptor 10): GET /fn/version HTTP/1.1
CONNECT   Apr 05 09:31:57 [10548]: Rewriting URL: /fn/version -> http://localhost:8081/version

Here's a test where the API URL is set incorrectly:

# Server is running on localhost:8080

vzarola-Mac:testing vzarola$ export FN_API_URL=http://localhost:8080/wrong-path/
vzarola-Mac:testing vzarola$ fn version
Client version is latest version: 0.5.69
Server version:  ?

[vzDevelopment]

Something to note, but is out of scope of this PR, is that the fn code will remove paths with a suffix of v1/. Therefore, if for whatever reason I had a reverse proxy of say /fn-routing/v1 then it won't work:

# Server is running on localhost:8080
# Reverse proxy is redirecting /fn-routing/v1 to localhost:8080

vzarola-Mac:testing vzarola$ fn version
Client version is latest version: 0.5.69
Server version:  ?

Proxy logs:

CONNECT   Apr 05 09:53:17 [15948]: Request (file descriptor 10): GET /fn-routing/version HTTP/1.1
ERROR     Apr 05 09:53:17 [15948]: Bad request, no mapping for '/fn-routing/version' found

Of course changing the v1 to something else does work:

# Server is running on localhost:8080
# Reverse proxy is redirecting /fn-routing/v99 to localhost:8080

vzarola-Mac:testing vzarola$ echo $FN_API_URL
http://localhost:8888/fn-routing/v99/
vzarola-Mac:testing vzarola$ fn version
Client version is latest version: 0.5.69
Server version:  0.3.687

Proxy logs

CONNECT   Apr 05 09:54:37 [16689]: Request (file descriptor 10): GET /fn-routing/v99/version HTTP/1.1
CONNECT   Apr 05 09:54:37 [16689]: Rewriting URL: /fn-routing/v99/version -> http://localhost:8080/version

I feel this is very unlikely to occur and not something we need to worry about

[rdallman]

Hi Reed, I'm not sure I fully understand - don't the last two test when the url.Path is an empty string?

oops, sorry, I glossed over the last one. LGTM

Something to note, but is out of scope of this PR, is that the fn code will remove paths with a suffix of v1/.

good find. this is probably a relic, /v1 API isn't supported anymore either, so we can probably remove these hacks from the provider here since they're dead at this point

[rdallman]

circleci seems messed up... looking into it, will get this merged though, thank you