On Wed, Aug 6, 2025 at 4:34 PM Florents Tselai <florents.tse...@gmail.com> wrote:
> 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.tse...@gmail.com> > wrote: > >> >> >> On 1 Aug 2025, at 1:13 PM, Florents Tselai <florents.tse...@gmail.com> >> wrote: >> >> >> On Tue, Jul 29, 2025 at 3:25 PM Daniel Gustafsson <dan...@yesql.se> >> wrote: >> >>> > On 12 Jul 2025, at 21:40, David E. Wheeler <da...@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. >> > v6 introduced some whitespace errors in the regression files. Here's a v7 that fixes that
v7-0001-Add-support-for-base64url-encoding-and-decoding.patch
Description: Binary data
