On Tue, Jul 1, 2025 at 1:09 PM Rowan Tommins [IMSoP] <imsop....@rwec.co.uk>
wrote:

>
>
> On 19 June 2025 12:01:04 BST, ignace nyamagana butera <nyamsp...@gmail.com>
> wrote:
> >RFC proposal link: https://wiki.php.net/rfc/data_encoding_api
>
> Thanks for working on this, I have often had to implement base64url and
> been frustrated it's not just a built-in option.
>
> I like the look of the new API. Using namespaced enums is currently quite
> verbose, but that's something we could try to fix at at the language level
> - e.g. Swift has some nice inference rules, so you can write the equivalent
> of base64_encode($string, ::UrlSafe).
>
> One thing I think the RFC should mention is the future of the existing
> base64_encode/decode functions. Am I right in thinking that with one
> parameter, the new namespaced versions will be identical to the old? If so,
> we have the option to make the existing functions aliases for the new. Or,
> we can leave them as-is, but plan to deprecate them. What we probably don't
> want is to indefinitely have two versions with such similar names but
> different signatures.
>
> Rowan Tommins
> [IMSoP]
>

 Hi Rowan,

Currently the RFC does not address deprecating the current functions for
the following reasons:

- The current base64_decode function operates in a lenient mode by default,
accepting characters outside the valid Base64 alphabet and ignoring
the padding character wherever it is in the string.

 base64_decode('dG9===0bw??', false); // returns 'toto'

However, the newly proposed lenient mode aligns with the stricter
recommendations of RFC 4648, Section 12
<https://www.rfc-editor.org/rfc/rfc4648.html#section-12>, which advise
rejecting inputs containing invalid characters due to potential security
concerns. Consequently, the behavior differs significantly: while the
current implementation tolerates non-alphabet characters and accepts
padding characters in positions other than at the end of the encoded
string, the proposed version enforces strict validation to enhance security
and compliance with the standard.

Encoding\base64_decode('dG90bw??', DecodingMode::Lenient); // will throw
because of RFC 4648 security recommendation character outside of the base64
alphabet
Encoding\base64_decode('dG9===0bw', DecodingMode::Lenient); // will throw
because of RFC 4648 security recommendation padding character not located
at the end of the string
Encoding\base64_decode('dG90bw', DecodingMode::Lenient); // returns 'toto'

- hex2bin always operates in a lenient mode—it does not support strict
validation. It could be replaced by the new base16_decode function when
configured with appropriate options. However, it's important to note that
the default behavior differs: unlike hex2bin, base16_decode defaults to
strict mode, rejecting invalid input by design, consistent with all newly
proposed decoding functions.

For those reasons, I believe a clear deprecation and removal strategy for
the current functions warrants its own dedicated RFC, as certain features
cannot be easily migrated to the new API.

Reply via email to