On Tue, Apr 13, 2021 at 04:44:38PM +0200, Moemen MHEDHBI wrote:
> > But then how about having just *your* functions
> > without relying on the other ones ? Now that you've extended the existing
> > function, you can declare it yours, remove all the configurable stuff and
> > keep the simplified ver
On 13/04/2021 11:39, Willy Tarreau wrote:
>> You can find attached the patches 0001-bis and 0002-bis modifying the
>> existing functions (introducing an url flag) to see how it looks like.
>> This solution may be cleaner (no chunk allocation and we don't loop
>> twice over input string) but has t
Hi Jarno,
On Tue, Apr 13, 2021 at 06:19:47AM +, Jarno Huuskonen wrote:
> Hello,
>
> On Tue, 2021-04-06 at 01:58 +0200, Moemen MHEDHBI wrote:
> > Thanks Willy and Tim for your feedback.
> >
> > You can find attached the updated patches with fixed coding style (now
> > set correctly in my edit
Hi Moemen,
On Tue, Apr 13, 2021 at 12:41:39AM +0200, Moemen MHEDHBI wrote:
> >> in such case should we rather use dynamic allocation ?
> >
> > No, there are two possible approaches. One of them is to use a trash
> > buffer using get_trash_chunk(). The trash buffers are "large enough"
> > for anyth
Hello,
On Tue, 2021-04-06 at 01:58 +0200, Moemen MHEDHBI wrote:
> Thanks Willy and Tim for your feedback.
>
> You can find attached the updated patches with fixed coding style (now
> set correctly in my editor), updated commit message, entry doc in sorted
> order, size_t instead of int in both en
On 12/04/2021 23:13, Aleksandar Lazic wrote:
> Hi Moemen,
>
> any chance to get this feature before 2.4 will be realeased?
>
> Regards
> Aleks
>
Hi Aleksandar,
I have updated the patch (attached) so it gets reviewed and eventually
merged.
I know this is going to be useful with what you are tr
Hi Moemen,
any chance to get this feature before 2.4 will be realeased?
Regards
Aleks
On 06.04.21 09:13, Willy Tarreau wrote:
Hi Moemen,
On Tue, Apr 06, 2021 at 01:58:11AM +0200, Moemen MHEDHBI wrote:
Only part unclear:
On 02/04/2021 15:04, Tim Düsterhus wrote:
+int base64urldec(const char
Hi Moemen,
On Tue, Apr 06, 2021 at 01:58:11AM +0200, Moemen MHEDHBI wrote:
> Only part unclear:
> On 02/04/2021 15:04, Tim Düsterhus wrote:
> >> +int base64urldec(const char *in, size_t ilen, char *out, size_t olen) {
> >> +char conv[ilen+2];
> >
> > This looks like a remotely triggerable stac
Thanks Willy and Tim for your feedback.
You can find attached the updated patches with fixed coding style (now
set correctly in my editor), updated commit message, entry doc in sorted
order, size_t instead of int in both enc/dec and corresponding reg-test.
Only part unclear:
On 02/04/2021 15:04,
Moemen,
On 4/2/21 1:38 AM, Moemen MHEDHBI wrote:
Subject: [PATCH 1/2] MINOR: sample: add ub64dec and ubase64 converters
ub64dec and ubase64 are the base64url equivalent of b64dec and base64
converters. base64url encoding is the "URL and Filename Safe Alphabet"
variant of base64 encoding. It is
Hi Moemen,
On Fri, Apr 02, 2021 at 01:38:59AM +0200, Moemen MHEDHBI wrote:
> I have came across the same use-case as Jonathan so I gave it a try and
> implemented the converters for base64url variant.
>
> - Regarding the converters name, I have just prefixed "u" and used
> ubase64/ub64dec. Let me
> On Mon, May 28, 2018 at 01:43:41PM +0100, Jonathan Matthews wrote:
>> Improvements and suggestions welcome; flames and horror -> /dev/null ;-)
>
> Would anyone be interested in adding two new converters for this,
> working exactly like base64/b64dec but with the URL-compatible
> base64 encoding i
12 matches
Mail list logo
