On Mon, Jan 9, 2023, at 12:49 PM, Sara Golemon wrote: > I've been working with JWTs lately and that means working with Base64URL > format. (Ref: https://www.rfc-editor.org/rfc/rfc4648#section-5 ) > This is essentially the same thing as normal Base64, but instead of '+' and > '/', it uses '-' and '_', respectively. It also allows leaving off the > training '=' padding characters. > > So far, I've just been including polyfills like this: > > function base64url_decode(string $str): string { > return base64_decode(str_pad(strtr($str, '-_', '+/'), (4 - > (strlen($str) % 4)) % 4, '=')); > } > > function base64_encode(string $str): string { > return rtrim(strtr(base64_encode($str), '+/', '-_'), '='); > } > > These work fine, but they create a LOT of string copies along the way which > shouldn't be necessary. > Would anyone mind if skipped RFC and just added `base64url_encode()` and > `base64url_decode()` to PHP 8.3? > > Can hold a vote if anyone objects, but this seems fairly non-controversial. > > -Sara
It sounds to me like there's enough discussion to be had on the How to warrant a formal RFC. I get the sense once the bikeshedding is done it will pass, but it's going to need the discussion/review. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
