add url encoding/decoding functions #62
Conversation
| } | ||
|
|
||
| func urlEncode(v string) string { | ||
| return url.QueryEscape(v) |
There was a problem hiding this comment.
Can you explain the use case for urlEncode?
To provide a little context...
url.QueryEscapeisn't meant for a full URL. Instead, it's meant for the Query string part of it.- The
html/templatepackage does automatic URL escaping. If you want to learn more about that see theescape.goandurl.gofiles.
So, this function (once for full URLs) would need a case outside of html templates.
There was a problem hiding this comment.
url.QueryEscape isn't meant for a full URL. Instead, it's meant for the Query string part of it.
This is both true and false. I think what you're saying is that if you encode http://www.example.com, you're going to end up with http%3A%2F%2Fwww.example.com, and you're absolutely right-- but it's probably not correct that nobody ever wants to do that. Imagine, for instance, the case where a URL needs to be passed as a query parameter within another url.
Although the above isn't my actual use case. It's just a good example. My real case is that I want to URL encode a password that some off-the-shelf software internally concatenates into a connection string without (shame on them) properly URL encoding it themselves.
I think whether we are talking about sprig template functions or just plain url.QueryEscape in go, what you do with it is relative to one's use case. It's probably not for us to decide how it's used, but rather just to provide the capability.
There was a problem hiding this comment.
I would need this to be able to create custom urls.
My goal is to create URL which would redirect to prometheus, e.g.:
https://prometheus.company.com/graph?g0.range_input=1h&g0.expr={{ urlEnc .query }}&g0.tab=1
|
Well... I just realized this won't actually help me because the value I want to encode is in a k8s secret. I can use the downward API to shim it into an env var, but I can't actually get at its value to carry out this encoding. I do still think this is generally useful functionality, but it's not longer important to me. @mattfarina I leave it to you whether you'd like to just close this. |
That's too bad.
That's exactly what I would need to do, too. |
Also, this grows the number of encoding/decoding functions to a point where I felt it was useful to split those functions out of
strings.gointo a new fileencoding.go-- same for the corresponding tests.