Go?Gin框架路由相關(guān)bug分析

更新時(shí)間：2023年12月14日 09:40:02 作者：cainmusic

這篇文章主要為大家介紹了Go?Gin框架路由相關(guān)bug分析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪

引言

注：本文原文有錯(cuò)誤，原文不改動(dòng)，但在結(jié)尾進(jìn)行了勘誤，注意讀到文章結(jié)尾。

Gin相關(guān)版本v1.9.1

當(dāng)你按如下方法注冊(cè)兩個(gè)路由的時(shí)候，bug會(huì)發(fā)生。

r := gin.Default()
    r.GET("/static/", func(c *gin.Context) { c.String(200, "static") })
    r.GET("/static/*file", func(c *gin.Context) { c.String(200, "static file") })
    r.Run()

上面的代碼會(huì)報(bào)錯(cuò)：

panic: runtime error: index out of range [0] with length 0

分析

雖然構(gòu)建路由樹(shù)的時(shí)候，Gin本身就會(huì)主動(dòng)產(chǎn)生很多panic，但上面這個(gè)panic顯然是個(gè)意外。

這個(gè)bug由catchAll通配符的特異性導(dǎo)致。

catchAll通配符雖然寫(xiě)作*paramname，但其構(gòu)建路由樹(shù)的時(shí)候會(huì)向前匹配一位/。

因?yàn)閏atchAll通配符通常是為了匹配路徑而存在的，catchAll通配符在gin中的經(jīng)典應(yīng)用就是配置靜態(tài)文件服務(wù)器。

參考gin項(xiàng)目的routergroup.go文件：

func (group *RouterGroup) StaticFS(relativePath string, fs http.FileSystem) IRoutes {
    if strings.Contains(relativePath, ":") || strings.Contains(relativePath, "*") {
        panic("URL parameters can not be used when serving a static folder")
    }
    handler := group.createStaticHandler(relativePath, fs)
    urlPattern := path.Join(relativePath, "/*filepath")
    // Register GET and HEAD handlers
    group.GET(urlPattern, handler)
    group.HEAD(urlPattern, handler)
    return group.returnObj()
}

一旦你使用Static相關(guān)函數(shù)配置靜態(tài)文件服務(wù)，最后都會(huì)調(diào)用到上面的方法。

其中用你傳入的relativePath和/*filepath組合為最終的url：relativePath/*filepath。

假如你傳入的路徑是/static，則最終url為/static/*filepath。

這個(gè)路由會(huì)匹配所有以/static/開(kāi)頭的url，并將后面的所有內(nèi)容賦值到filepath。

沒(méi)錯(cuò)，是所有，包括后面的/，比如html/group1/page1.html，也就是說(shuō)可以通過(guò)filepath訪問(wèn)到子目錄。

但上面描述的內(nèi)容實(shí)際上有一個(gè)錯(cuò)誤，你以為filepath保存的內(nèi)容是html/group1/page1.html。

實(shí)際上是/html/group1/page1.html。

catchAll通配符會(huì)嘗試向前多匹配一個(gè)/，如果你的路由中沒(méi)有這個(gè)/，會(huì)報(bào)錯(cuò)。

這個(gè)特性的特異之處導(dǎo)致gin中有一個(gè)bug，就是當(dāng)你已經(jīng)注冊(cè)了/static/路由之后，再注冊(cè)/static/*file的時(shí)候，我們會(huì)在/static/節(jié)點(diǎn)上插入*filepath而不是/*filepath，這導(dǎo)致在程序判斷這是一個(gè)catchAll路由后，會(huì)去向前匹配一位/，這時(shí)i--后，變成了負(fù)數(shù)，就導(dǎo)致了index out of range的錯(cuò)誤。

你可能會(huì)覺(jué)得報(bào)錯(cuò)是對(duì)的啊，那么你需要注意分清報(bào)錯(cuò)和bug產(chǎn)生的panic。

i--
if path[i] != '/' {
    panic("no / before catch-all in path '" + fullPath + "'")
}

我說(shuō)的報(bào)錯(cuò)產(chǎn)生在panic("no / before catch-all in path '" + fullPath + "'")。

而bug產(chǎn)生的panic產(chǎn)生在i--變?yōu)樨?fù)數(shù)后查詢if path[i] != '/'時(shí)。

簡(jiǎn)單處理的話，這里應(yīng)該對(duì)i的值進(jìn)行判斷，然后主動(dòng)panic拋出可以讓人領(lǐng)悟的報(bào)錯(cuò)。

當(dāng)然，為了解決這個(gè)問(wèn)題本身，可以將上面的代碼修改為：

r := gin.Default()
    r.GET("/static", func(c *gin.Context) { c.String(200, "static") })
    r.GET("/static/*file", func(c *gin.Context) { c.String(200, "static file") })
    r.Run()

第一個(gè)路由不要加末尾的/，就可以規(guī)避這個(gè)bug。

勘誤

前文提到panic: runtime error: index out of range [0] with length 0報(bào)錯(cuò)，但這顯然不是index為負(fù)的報(bào)錯(cuò)，是我之前預(yù)判i--為負(fù)時(shí)一廂情愿了。

實(shí)際上這個(gè)錯(cuò)誤發(fā)生在i--的上面幾行：

if len(n.path) > 0 && n.path[len(n.path)-1] == '/' {
    pathSeg := strings.SplitN(n.children[0].path, "/", 2)[0]
    panic("catch-all wildcard '" + path +
        "' in new path '" + fullPath +
        "' conflicts with existing path segment '" + pathSeg +
        "' in existing prefix '" + n.path + pathSeg +
        "'")
}
// currently fixed width 1 for '/'
i--
if path[i] != '/' {
    panic("no / before catch-all in path '" + fullPath + "'")
}

這一行：pathSeg := strings.SplitN(n.children[0].path, "/", 2)[0]。

這里的children長(zhǎng)度實(shí)際為0，但這里卻默認(rèn)children有內(nèi)容。

看panic報(bào)錯(cuò)的內(nèi)容：catch-all wildcard "path" in new path "fullPath" conflicts with existing path segment "pathSeg" in existing prefix "n.path" + "pathSeg"。

大意上還是catchAll通配符和當(dāng)前路徑?jīng)_突，但這里Gin默認(rèn)此時(shí)n.children不為空的邏輯我還是沒(méi)太想明白。

以上就是Go Gin框架路由相關(guān)bug分析的詳細(xì)內(nèi)容，更多關(guān)于Go Gin框架路由bug的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章: