Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119243
MIME-Version: 1.0
Date: Mon, 9 Jan 2023 12:49:28 -0600
Message-ID: <CAESVnVo3NyM_RGybyLQSko0F=fBSnSWG3gkVZtU-DS8W=79fdA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c181bb05f1d93a78"
Subject: base64url format
From: pollita@php.net (Sara Golemon)

--000000000000c181bb05f1d93a78
Content-Type: text/plain; charset="UTF-8"

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

--000000000000c181bb05f1d93a78--