2013= /4/18 adacosta (Alan Da Costa) <alandacosta@gmail.com>

Issue #8286 has been updated by adacosta (Alan Da Costa).

My confusion on this issue might have stemmed from a client sending Base64 = without padding, and decode64 not managing to decode the base64, for exampl= e:

> Base64.decode64 "TG9yZW0gaXBzdW0gZG9sb3Igc2l0IGFtZXQsIGNvbnNlY3Rl= dHVyIGFkaXBpc2NpbmcgZWxpdC4"
=A0=3D> "Lorem ipsum dolor sit amet, consectetur adipiscing eli&quo= t;

Using python
=A0 base64.b64decode('TG9yZW0gaXBzdW0gbase64Igc2l0IGFtZXQsIGNvbnNlY3Rld= HVyIGFkaXBpc2NpbmcgZWxpdC4')
=A0 TypeError: Incorrect padding

Using node.js
=A0 > new Buffer("TG9yZW0gaXBzdW0gZG9sb3Igc2l0IGFtZXQsIGNvbnNlY3Rld= HVyIGFkaXBpc2NpbmcgZWxpdC4", 'base64').toString('ascii'= ;)
=A0 'Lorem ipsum dolor sit amet, consectetur adipiscing elit.'

This was an old issue for me. My problem seems to have been the padding is = not necessary to decode the string. I suppose the behavior of how this is h= andled is not explicit. I don't expect Ruby to magically figure out the= issue, but its behavior seems to be different from other languages in that= it doesn't raise an error or succeed with the output.

What are your thoughts on this? Are there other common language implementat= ions that won't decode the "t." ?

After I read RFC again, I found=A0base64url allows to skip padding.

So I'll allow= Base64.decode64 to implicit paddings.

Note that Base64.strict_decode64 raises= error like python

--14dae9cdcaad87246904da9ac9e8--