Re: encode/decode support for base64url
От | Florents Tselai |
---|---|
Тема | Re: encode/decode support for base64url |
Дата | |
Msg-id | C8505658-D9B9-4519-81AC-EB48CFA24037@gmail.com обсуждение исходный текст |
Ответ на | Re: encode/decode support for base64url (Florents Tselai <florents.tselai@gmail.com>) |
Ответы |
Re: encode/decode support for base64url
|
Список | pgsql-hackers |
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 uses '-' 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.
Вложения
В списке pgsql-hackers по дате отправления: