On Tue, Jan 10, 2023 at 8:44 AM Larry Garfield
wrote:
>
> > Can hold a vote if anyone objects, but this seems fairly
non-controversial.
> >
>
> It sounds to me like there's enough discussion to be had on the How to
warrant a formal RFC. I get the sense once the bikeshedding is done it
will pass,
On Mon, Jan 9, 2023, at 12:49 PM, Sara Golemon 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 '_
how about base64_encode(string $string, int $flags = 0): string
with $flags accepting BASE64_RFC4648 and BASE64_NO_PADDING
or something to that effect?
On Mon, 9 Jan 2023 at 22:56, David Gebler wrote:
>
> On Mon, Jan 9, 2023 at 9:42 PM Derick Rethans
> wrote:
>
> > On 9 January 2023 18:49:28 GMT
On Mon, Jan 9, 2023 at 9:42 PM Derick Rethans
wrote:
> On 9 January 2023 18:49:28 GMT, Sara Golemon 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 norm
On 9 January 2023 18:49:28 GMT, Sara Golemon 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 '_', re
when http_build_query() wanted to support different encoding schemes,
PHP_QUERY_RFC1738 and PHP_QUERY_RFC3986 was made, instead of creating
http_build_query_rfc1738() and http_build_query_rfc3986() , hmm
On Mon, 9 Jan 2023 at 21:12, Tim Düsterhus wrote:
>
> Hi
>
> On 1/9/23 19:49, Sara Golemon wr
Hi
On 1/9/23 19:49, Sara Golemon 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
I'm in support of such a feature, but would strongly advocate for an
additional parameter to flag whether or not to include the trailing `=`
pad. The trailing pad is optional according to RFC 4648, so I think
leaving it off by default would be the ideal use case, but an optional
`include_paddin
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 '=' p
