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.
