base64.urlsafe_b64encode() almost always returns strings that include the = character. this may be ok before the ? in a URL, but it's not OK after.

it would be nice if it substituted another character for =, like it does for + and /. if this is intentional, though, and you don't want to substitute for =, the documentation should probably be changed to note that it's only safe for use before the ?. (it doesn't include that caveat now.)

http://docs.python.org/lib/module-base64.html#l2h-1592

after more investigation, RFC3548 does say to use the = character for padding even in the URL-safe alphabet. weird.

so, it looks like the base64 module is just following the spec, and it's the spec that (seems) broken. sigh.

i'm off to try to figure out why RFC3548 says = is ok in URLs...

i talked to harald alvestrand, and he made the good point that the = character is only problematic in URL parameter names. it's ok, if unusual, in parameter values, since the & character is used at the end the value.

apart from that, though, he didn't sound like this would be a priority for the IETF to address. unfortunate, but understandable. :P

so, the resolution here might just be to update the base64 documentation to say that urlsafe_b64encode's output may include the = character. another option would be to change the code to use different character for padding, which would be nicer, but wouldn't follow the spec. up to you.

Not following the spec doesn't seem reasonable. Adding a caveat about
how we follow the spec doesn't make much sense (I started to write one
and dropped it at "The resulting string" :D).

Added a short note in r69576.