search

gin-gonic / gin

Gin is a HTTP web framework written in Go (Golang). It features a Martini-like API with much better performance -- up to 40 times faster. If you need smashing performance, get yourself some Gin.
https://gin-gonic.com/
MIT License
76.77k stars 7.92k forks source link

Defferent Group Router Result For v1.7.1, v.1.7.4, v1.7.7 #3019

Open LawyZheng opened 2 years ago

LawyZheng commented 2 years ago

Description

I don't know whether it is a bug or a change to the latest version. I just want to know how to use it for the next version updating.

I get some routers as follow:

router.GET("/:a", func(c *gin.Context) { c.String(http.StatusOK, ":"+c.Param("a")) })
group := router.Group("/group")
{
    group.GET("/*b", func(c *gin.Context) { c.String(http.StatusOK, "*"+c.Param("b")) })
}

I run some cases to test the routers. /cc, which is supposed to be returned as :cc. /cC, which is supposed to be returned as :cC. /group, which is supposed to be returned as */. This is the case that differs from the various versions. /group/1, which is supposed to be returned as */1.

I test these cases in v1.7.1, v.1.7.4, v1.7.7. I got three different results.

For v1.7.1 It passed all tests, and the log shows routers had been redirected.

[GIN-debug] GET    /:a                       
[GIN-debug] GET    /group/*b              
[GIN] 2022/01/10 - 16:08:43 | 200 |       531.4µs |       127.0.0.1 | GET      "/cc"
[GIN] 2022/01/10 - 16:08:43 | 200 |            0s |       127.0.0.1 | GET      "/cC"
[GIN-debug] redirecting request 301: /group/ --> /group/
[GIN] 2022/01/10 - 16:08:43 | 200 |            0s |       127.0.0.1 | GET      "/group/"
[GIN] 2022/01/10 - 16:08:43 | 200 |            0s |       127.0.0.1 | GET      "/group/123"

For v1.7.4 It passed three tests, except the 3rd one. And the log didn't show that routers had been redirected.

[GIN-debug] GET    /:a                    
[GIN-debug] GET    /group/*b              
[GIN] 2022/01/10 - 16:21:21 | 200 |            0s |       127.0.0.1 | GET      "/cc"
[GIN] 2022/01/10 - 16:21:21 | 200 |       507.6µs |       127.0.0.1 | GET      "/cC"
[GIN] 2022/01/10 - 16:21:21 | 200 |            0s |       127.0.0.1 | GET      "/group"
Expected: */, Got: :
[GIN] 2022/01/10 - 16:21:21 | 200 |            0s |       127.0.0.1 | GET      "/group/123"

It shows that not only the router is matched differently compared to v1.7.1, but also the param is omitted.

For v1.7.7 It passed three tests, except the 3rd one. And the log didn't show that routers had been redirected.

[GIN-debug] GET    /:a                      
[GIN-debug] GET    /group/*b         
[GIN] 2022/01/10 - 16:25:34 | 200 |       517.3µs |       127.0.0.1 | GET      "/cc"
[GIN] 2022/01/10 - 16:25:34 | 200 |            0s |       127.0.0.1 | GET      "/cC"
[GIN] 2022/01/10 - 16:25:34 | 200 |            0s |       127.0.0.1 | GET      "/group"
Expected: */, Got: :group
[GIN] 2022/01/10 - 16:25:34 | 200 |            0s |       127.0.0.1 | GET      "/group/123"

It shows the param had been parsed correctly, but the router is still different compared to v1.7.1.

Expectations

Then I add an empty router in the group to fix this problem in v1.7.4 and v1.7.7, and it passed all tests successfully.

    group.GET("", func(c *gin.Context) { c.String(http.StatusOK, "*/") })

As I said, I don't know whether it is a bug or a change. I'm just confused about how to use it, considering the future updating for the router matching rule.

Environment

Bisstocuz commented 2 years ago

There are some router bugfixes in update, perhaps you mistakenly believe that the incorrect results in v1.7.1 and v1.7.4 are correct.

I believe it's not a bug, /group should match /:a and /group/ should match /group/*b. It's expected.