Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119253
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1185-g841157300a-fm-20221208.002-g84115730
Mime-Version: 1.0
Message-ID: <2c700f58-cdb6-49b1-b40a-b92cc69bf0fe@app.fastmail.com>
In-Reply-To: 
 <CAESVnVo3NyM_RGybyLQSko0F=fBSnSWG3gkVZtU-DS8W=79fdA@mail.gmail.com>
References: 
 <CAESVnVo3NyM_RGybyLQSko0F=fBSnSWG3gkVZtU-DS8W=79fdA@mail.gmail.com>
Date: Tue, 10 Jan 2023 08:43:39 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] base64url format
From: larry@garfieldtech.com ("Larry Garfield")

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