Thread

Re: encode/decode support for base64url

Florents Tselai <florents.tselai@gmail.com> — 2025-08-06T13:34:52Z

Attaching v6 again because it wasn't picked up the last time.
Trying from Gmail's web page this time.



On Tue, Aug 5, 2025 at 12:40 PM Florents Tselai <florents.tselai@gmail.com>
wrote:

>
>
> On 1 Aug 2025, at 1:13 PM, Florents Tselai <florents.tselai@gmail.com>
> wrote:
>
>
> On Tue, Jul 29, 2025 at 3:25 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>
>> > On 12 Jul 2025, at 21:40, David E. Wheeler <david@justatheory.com>
>> wrote:
>>
>> > Thank you! This looks great. The attached revision makes a a couple of
>> minor changes:
>>
>> I also had a look at this today and agree that it looks pretty close to
>> being
>> done, and a feature we IMHO would like to have.
>
>
> Thanks for having a look Daniel!
>
>
>>
>>
> The attached version also adds a commit message, tweaks the documentation
>> along
>> with a few small changes to error message handling etc.
>>
>
> In the doc snippet
>
> > The base64url alphabet use '-' instead of '+' and '_' instead of '/' and
> also omits the '=' padding character.
>
> Should be
>
> > The base64url alphabet use*s* '-' instead of '+' and '_' instead of '/'*,
> *and also omits the '=' padding character.
>
> I'd also add a comma before "and also"
>
>
>> The base64 code this extends is the RFC 2045 variant while base64url is
>> based
>> on base64 from RFC 3548 (obsoleted by RFC 4648).  AFAICT this is not a
>> problem
>> here but has anyone else verified this?
>>
>
> I don't see how this can be a problem in practice.
> The conversions are straightforward,
> and the codepath used with url=true is a new one and doesn't change past
> behavior.
>
>
> Here’s a v6; necessary because func.sgml was split .
> No other changes compared to v5.
>
>
>