Can't unescape multi byte path parameters

[lon9]

/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
/ / / / / / / / / / / / / / / / / /

Please use forum https://forum.labstack.com to ask questions!

/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
/ / / / / / / / / / / / / / / / / /

Issue Description

c.Params can't unescape when the parameter is a small case percent encoded string like %e3%81%93%e3%82%93%e3%81%ab%e3%81%a1%e3%82%8f
but it can unescape a big case like %E3%81%93%E3%82%93%E3%81%AB%E3%81%A1%E3%82%8F

With default template engine in Go escapes multi byte in href to small case percent encoded string automatically, so we can't get unescaped string.

The cause is here.
In the case of a small case, r.RawPath becomes /%e3%81%93%e3%82%93%e3%81%ab%e3%81%a1%e3%82%8f so we get a escaped parameter. but in the case of a big case, r.RawPath becomes empty so we get a unescaped parameter from r.Path
Example playground

Checklist

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

Expected behaviour

We can get a unescaped path parameter.

Actual behaviour

We can get a escaped path parameter.

Steps to reproduce

Passing small case percent encoded string as path parameter.

Working code to debug

package main

import (
	"net/http"

	"github.com/labstack/echo"
)

func main() {
	e := echo.New()
	e.GET("/:tag", func(c echo.Context) error {
		return c.String(http.StatusOK, c.Param("tag"))
	})
	e.Logger.Fatal(e.Start(":1323"))
}

Access to localhost:1312/%e3%81%93%e3%82%93%e3%81%ab%e3%81%a1%e3%82%8f and localhost:1323/%E3%81%93%E3%82%93%E3%81%AB%E3%81%A1%E3%82%8F
then we can get different responses %e3%81%93%e3%82%93%e3%81%ab%e3%81%a1%e3%82%8f and こんにちわ

Version/commit

f867058

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nekketsuuu]

This should be fixed to normalize paths by framework-side. I think it's better to keep this issue open.

[alexaandru]

Yup, this looks like a bug. And I agree that the bug is the automatic unescape. Since this "thing" is marked as a parameter, the handler should receive the data exactly as is, it is not the job of the framework to interpret the data in behalf of the user.

[alexaandru]

Thoughts about this @vishr @im-kulikov ?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nekketsuuu]

So which side should unescape a url, framework-side or user-side?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nekketsuuu]

Hmm... it seems that there is no strong motivation to choose the design.