more relaxed Base64 decoding

[karel-m]

Hi,

I would like to propose more relaxed Base64 decoding (the patch does not affect encoding). By more relaxed I mean that we do not insist on a correct number of = at the end of Base64 input.

In fact with this patch we ignore = in a same way as we ignore other unwanted characters.

Without this patch base64url_decode does not follow RFC 4648 section 5 which requires to ignore tailing = (yes it was commited by me, completely my fault :).

--Karel

[sjaeckel]

This is clashing with #106 and I prefer having strict checks instead of relaxed ones.
Do you think it'd make sense to integrate these changes in #106 under consideration of the strict flag?

[karel-m]

When talking about RFC4648 there is also section 5 which defines so called base64 URL Safe variant implemented in base64url_decode (implementation is mine and is buggy, which I was about to fix by this PR).

So if #106 declares it implements strict mode according RFC4648 it should perhaps handle also section 5 not only "standard" base64.

As for the strict/relaxed mode in base64url mode:

• let us have "standard" base64 string: vuiSPKIl8PiR5O+rC4z9/xTQKZ0=
• strict URL safe variant looks like: vuiSPKIl8PiR5O-rC4z9_xTQKZ0
• relaxed variant (with trailing =): vuiSPKIl8PiR5O-rC4z9_xTQKZ0=
• relaxed variant (extra invalid chars): vuiS*PKIl8P*iR5O-rC4*z9_xTQKZ0
• relaxed variant (combined): vuiS*PKIl8P*iR5O-rC4*z9_xTQKZ0=

Currently base64url_decode is not able to parse vuiSPKIl8PiR5O-rC4z9_xTQKZ0 neither in strict nor in relaxed mode (with or without #106).

I can fix relax mode on top of #106 so that it accepts missing trailing = as well as it ignores invalid chars. But first we should perhaps fix the strict mode to correctly handle also base64url variant.

[sjaeckel]

• strict URL safe variant looks like: vuiSPKIl8PiR5O-rC4z9_xTQKZ0
• relaxed variant (with trailing =): vuiSPKIl8PiR5O-rC4z9_xTQKZ0=

Do I understand correctly and it's the inverse?!
The one with trailing = is strict (as of [1]) and the one without = is relaxed (as of [2]), right?

[1] Ch 3.2

Implementations MUST include appropriate pad characters at the end of encoded data unless the specification referring to this document explicitly states otherwise.

[2] Ch 5

...if the data length is known implicitly, this can be avoided by skipping the padding; see section 3.2.

The can makes it optional for me and therefor the version with = becomes the strict one...

The only thing that is clear is that this part is pretty unclear... at least I don't get it...

[sjaeckel]

Can you please have a look at #106 again and close this PR if you're fine with the solution implemented there?

[sjaeckel]

*ping* @karel-m

[karel-m]

I am closing this PR as it is now handled by #106