Parameter name affects route registration ordering

[filet0fish]

Issue Description

Routes with identical parameter names can return the wrong value if not registered in a specific order.

Checklist

• Dependencies installed
• No typos
• Searched existing issues and docs

Expected behaviour

Routing documentation states "Routes can be written in any order."

Actual behaviour

Route order does matter in this edge case. If registered in the wrong order, the parameter names resolve to the wrong segment of the url pattern.

Steps to reproduce

Register a set of route patterns:

e.GET("/:a/:b/:c/:id", func(c echo.Context) error {
	return c.HTML(500, "FAILS :id returns value of :c")
})
e.GET("/:a/:id", func(c echo.Context) error {
	return c.HTML(200, "WORKS")
})
e.GET("/:a/:e/:id", func(c echo.Context) error {
	return c.HTML(200, "WORKS")
})

If the first route is moved to last position, all will return the correct value for c.Param("id"). If any one of the 3 routes is removed, the other two will return the correct value.

Working code to debug

package main

import "github.com/labstack/echo"

func main() {
	e := echo.New()

	e.GET("/:a/:b/:c/:id", func(c echo.Context) error {
		return c.HTML(500, "FAILS :id returns :c, ID == "+c.Param("id"))
	})
	e.GET("/:a/:id", func(c echo.Context) error {
		return c.HTML(200, "WORKS, ID == "+c.Param("id"))
	})
	e.GET("/:a/:e/:id", func(c echo.Context) error {
		return c.HTML(200, "WORKS, ID == "+c.Param("id"))
	})

	e.Logger.Fatal(e.Start(":8888"))
}

http://localhost:8888/foo/bar/baz/123 returns FAILS :id returns :c, ID == baz

Version/commit

version: ^3.1.0
version: b338075

[vishr]

This came up from a commit fd9508c towards path param aliases. I am going to revert that change as it is buggy.

[vishr]

@filet0fish please verify.

[filet0fish]

Thanks, that fixed my test case.

We are still seeing some inconsistencies around registration order in our production app, but it appears to be unrelated. I will file another bug once we rule our code, have a good test case, and confirm the issue isn't a dupe of #875.

Our current workaround is sorting routes by complexity (number of params, then number of segments) and length before registering them.

Thanks again!