jinja: urlencode doesn't escape slashes

That’s fair enough but in practice it’s not necessary there either and included credentials are deprecated anyways. Since those are unlikely to be produced within templates it’s an edge case that is not really worth considering.

I hit this issue when trying to create a file in a gitlab repository via API calls. The gitlab api requires the slashes to be encoded. To make this work I do: {{ myvar | urlencode | regex_replace(‘/’,‘%2F’) }}. I’m working with Ansible and Jinja2 filters in my playbook tasks. This could be a workaround for those of you hitting this, as I validated it works.

@mitsuhiko Why does Jinja include any built-in filters then? I can only guess it is because they’re useful in multiple use cases. I used Ansible and Salt as two examples of where being able to escape slashes in URLs is desired, and hence, it would be valuable to have it available for everyone.

What about adding a safe argument to urlencode, as Python’s urllib.url_quote has, so that by default slashes are preserved, but in a way that can be easily overriden?

I want to close this because it came up again. My arguments against having this were up already in here earlier but I want to reiterate them because there is actually a PR open currently (#864) which proposes to add another filter for it to help GitLab’s API.

GitLab’s API broken if placed behind all kinds of proxy setups and there are issues open for it (Example Issue). I would instead propose to document a workaround and why people should not do it.

Example workaround could be this:

{{ value|urlencode|replace("/", "%2f") }}

This is a bit taking a stance but doing this can encourage people not to repeat the mistakes of others that came before them.

So the only part where a slash actually makes sense encoding is in query strings and this is where the dict based encoder that urlencode has works like that. However even there a slash does not have to be encoded, so there is no reason to force it to be encoded.

No, for example you need to encode / in usernames and passwords as well. It’s the reason why JS has encodeURI and encodeURIComponent.

Ansible uses Jinja, and it’s pretty common to handle security credentials when setting up systems. I just hit a case where an automatically-generated password contained a slash that was not replace by urlencode to generate a database URL, which is pretty unfortunate. While breaking current behavior would be problematic, why not introduce a second filter that does escape the slashes?