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-0001-Add-support-for-base64url-encoding-and-decoding.patch
Description: Binary data
