gin-gonic
Why gin.Context.Cookie has to do url.QueryUnescape?
- go version: go1.11.2 darwin/amd64
- gin version (or commit ref): v1.3.0
- operating system: macos/linux
Description
Gin replace + sign with whitespace (probably) due to url.QueryUnescape. We need to replace it back to original + sign and then encode to make it back to original value.
The code in question: https://github.com/gin-gonic/gin/blob/master/context.go#L741
If you look at how http package get cookie, it does not unescape the value and return just a string. I would like to know what's the decision to unescape value here.
FYI, it breaks our app, and we need to do a workaround by replacing " " (whitespace) back to +.
Same problem here! Any application that encodes cookie values using base64 encoding will sometimes break silently (in base64, + is allowed). I would find it helpful if at least a warning was printed.
RFC 6265 even recommends base64 as encoding:
To maximize compatibility with user agents, servers that wish to store arbitrary data in a cookie-value SHOULD encode that data, for example, using Base64 [RFC4648].
In my case, some users were not able to log in, as they were unfortunate enough to have a + in their decryption key. This is unexpected behavior, especially after migrating from a fully working net/http implementation. Why would gin handle cookies differently, especially if it uses the original net/http methods to retrieve the cookie (from context.go):
// Cookie returns the named cookie provided in the request or
// ErrNoCookie if not found. And return the named cookie is unescaped.
// If multiple cookies match the given name, only one cookie will
// be returned.
func (c *Context) Cookie(name string) (string, error) {
cookie, err := c.Request.Cookie(name)
if err != nil {
return "", err
}
val, _ := url.QueryUnescape(cookie.Value)
return val, nil
}
[1] RFC 6265 [2] StackOverflow
Any more progress on this one? I think gin need to comply with RFC6265
so the usage QueryEscape leads to unexpected url encoding
https://github.com/gin-gonic/gin/pull/3683#issuecomment-2229336611
A possible reason is to maintain compatibility with other web frameworks. This behavior could be turned into a flag to clarify the intend and use cases.
