Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119250
MIME-Version: 1.0
References: <CAESVnVo3NyM_RGybyLQSko0F=fBSnSWG3gkVZtU-DS8W=79fdA@mail.gmail.com>
 <A93F2A9D-BA70-4C0D-8496-581B0DA0C829@derickrethans.nl>
In-Reply-To: <A93F2A9D-BA70-4C0D-8496-581B0DA0C829@derickrethans.nl>
Date: Mon, 9 Jan 2023 21:56:15 +0000
Message-ID: <CA+p1FaacnhCr9715ar8FQc-Tv2a8mUe6hZCoMw17kKBQzzhDcQ@mail.gmail.com>
To: Derick Rethans <derick@derickrethans.nl>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a4f9ad05f1dbd66a"
Subject: Re: [PHP-DEV] base64url format
From: davidgebler@gmail.com (David Gebler)

--000000000000a4f9ad05f1dbd66a
Content-Type: text/plain; charset="UTF-8"

On Mon, Jan 9, 2023 at 9:42 PM Derick Rethans <derick@derickrethans.nl>
wrote:

> On 9 January 2023 18:49:28 GMT, Sara Golemon <pollita@php.net> 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?
>
> Should these be new functions, or options to base64_encode instead? I'd
> guess base64_decode could just accept both?


I think from a UX/DX perspective, separate functions would be my
preference, base64_url_encode and base64_url_decode (extra underscore which
I feel is more consistent with PHP stock library). One consideration though
is that base64_urlencode or base64_url_encode are function names which are
likely already defined by a number of userland projects or libraries, since
it's a very common thing to do with the prevalence of JWTs, so if the RFC
process is being bypassed in this case, a new optional parameter to
base64_encode might be better. But I think it would be weird to have
base64_encode(bool $urlEncode = false) or something, which is presumably
what it would look like.

Dare I float the suggestion of a Base64 class, making base64_encode and
base64_decode functions aliases for Base64::encode() and Base64::decode()
respectively, then new Base64::urlEncode() and urlDecode() methods?

--000000000000a4f9ad05f1dbd66a--