v3: Regression of #119

[nf-brentsaner]

Looks like at least when using <resty.Client>.SetBaseURL(), the trailing slash is removed.

This was previously addressed in v1.2 as reported in #119 and it seems to have reared its head again.

[jeevatkm]

@nf-brentsaner Thanks for reaching out.

I understand you're taking about Resty v1; however, there have been lots of improvements in the Resty v2 on the July 2019 release. Request URL behaviour was handled appropriately in v2, and the same behavior is present in Resty v3.

Do you mind providing an example and impact details of removing the trailing slash in Client.SetBaseURL?

[nf-brentsaner]

Please re-read. This is occurring in v3, I said it was previously occurring in v1.2 and is now back - i.e. a regression, as the title says.

Proof right here:

package main

import (
        "fmt"

        `resty.dev/v3`
)

const (
        tgtUrl string = "http://example.com/"
        tgtUrlBad string = "http://example.com"
)

var (
        c *resty.Client = resty.New().SetBaseURL(tgtUrl)
)

func main() {

        fmt.Printf(
                "Client created with URL '%s'.\n"+
                "Current Base URL: '%s'\n"+
                "tgtUrl == c.BaseURL(): %v\n\n",
                tgtUrl,
                c.BaseURL(),
                tgtUrl == c.BaseURL(),
        )

        for _, s := range []string {
                tgtUrl,
                tgtUrlBad,
        } {
                fmt.Printf("c.BaseURL matches '%s': %v\n", s, c.BaseURL() == s)
        }
}

Outputs:

Client created with URL 'http://example.com/'.
Current Base URL: 'http://example.com'
tgtUrl == c.BaseURL(): false

c.BaseURL matches 'http://example.com/': false
c.BaseURL matches 'http://example.com': true

And latest confirmed with go.mod:

module testgo

go 1.25.4

require resty.dev/v3 v3.0.0-beta.4

require golang.org/x/net v0.47.0 // indirect

Even happens against current v3 branch HEAD, latest commit:

$ cat go.mod ; echo "====="; go run main.go
module testgo

go 1.25.4

require resty.dev/v3 v3.0.0-beta.4.0.20251126081126-79f5cf9c2322

require golang.org/x/net v0.47.0 // indirect
=====
Client created with URL 'http://example.com/'.
Current Base URL: 'http://example.com'
tgtUrl == c.BaseURL(): false

c.BaseURL matches 'http://example.com/': false
c.BaseURL matches 'http://example.com': true

[nf-brentsaner]

As for impacts:

• When I set a BaseURL, I expect it to remain as I set it.
• Setting a URL with an explicit / URI path avoids a round-trip to e.g. NGINX servers.

Explicitly, setting BaseURL to a URL with a path explicitly of /, I would expect to be able to use c.R().Get(""), or c.R().SetURL(""), and use / as the URL path.

However, since the / path is stripped, it instead sets the URL path as empty.
I set the URL path as /, I expect it to remain as /, and thus setting a request's URL as an empty string should evaluate to /, not an empty string.

I noticed this with <resty.Request>.Send(), but I presume the same is present on .Get() et. al.

[jeevatkm]

@nf-brentsaner Thanks for the details and explanation. I will have a look and compare Resty’s previous versions with v3.

[jeevatkm]

@nf-brentsaner As I mentioned above, I will do the analysis using your code snippet, compare it, and get back to you.

However, my 2 cents -

Usage of c.R().Get(""), or c.R().SetURL("")

It is not an appropriate usage. It is best to use an explicit request path in the code flow, like c.R().Get("/") without assumptions. It makes the code flow digestible while reading/reviewing.

[nf-brentsaner]

It is not an appropriate usage. It is best to use an explicit request path in the code flow, like c.R().Get("/") without assumptions. It makes the code flow digestible while reading/reviewing.

I do not see this API expectation documented anywhere. The usage I describe (.Get("")) directly mimics other libraries' implementation of high-level HTTP clients (e.g. Python's requests/requests_toolbelt.sessions.BaseUrlSession).