ince padding is
mandatory where applicable with such a variant. For clarity, I will
revise the RFC to explicitly state the behavior of each encoding
variant during strict mode decoding.
Best regards,
Ignace Nyamagana Butera
Wed, Jul 2, 2025, at 2:25 PM, ignace nyamagana butera wrote:
> >>
> >> I don't think it needs to be added to the enum, necessarily. Just make
> it a nullable argument to base64_decode.
> >>
> >> function base64_decode(string $string, bool $
>
>
> I don't think it needs to be added to the enum, necessarily. Just make it
> a nullable argument to base64_decode.
>
> function base64_decode(string $string, bool $strict = false, ?DecodingMode
> = null): string|false
>
> That would leave the default behavior of the function intact, but also
>
> > Perhaps we should include an option in the new API to emulate the old
> behaviour, named as "legacy" or "unsafe" and immediately soft-deprecated
> with a note in the manual, similar to the MT_RAND_PHP mode in the
> Randomizer API <
> https://www.php.net/manual/en/random-engine-mt19937.constru
Fri, Jun 20, 2025, at 3:17 AM, ignace nyamagana butera wrote:
>
> > - it'd be great to default to url-safe base64. The RFC-compliant
> > variant is a very common risk, it'd be great to be on the safe side by
> > default
> >
> > I went with the RFC re
On Tue, Jul 1, 2025 at 1:09 PM Rowan Tommins [IMSoP]
wrote:
>
>
> On 19 June 2025 12:01:04 BST, ignace nyamagana butera
> wrote:
> >RFC proposal link: https://wiki.php.net/rfc/data_encoding_api
>
> Thanks for working on this, I have often had to implement base64url an
Hi all,
I have updated the RFC (https://wiki.php.net/rfc/data_encoding_api) to
include base58 encoding and decoding functions to the proposal with
arguments in favor of the addition.
Best regards,
Ignace
On Fri, Jun 20, 2025 at 10:17 AM ignace nyamagana butera <
nyamsp...@gmail.com>
C proposal link: https://wiki.php.net/rfc/data_encoding_api
>> If passed, Tim Düsterhus has volunteered to do the implementation.
>>
>> Thanks in advance for your remarks and comments.
>>
>> Best regards,
>> Ignace Nyamagana Butera
>>
>
> Thanks for the
Best regards,
Ignace Nyamagana Butera
Greetings all,
Following the brief introduction of my RFC4648 proposal for PHP (
https://news-web.php.net/php.internals/127656) I would like to request RFC
karma.
My wiki account is: nyamsprod.
Thank you in advance.
Ignace Nyamagana Butera
On Thu, Jun 12, 2025 at 7:23 PM Hans Henrik Bergan
wrote:
> On Thu, 12 Jun 2025 at 18:53, ignace nyamagana butera
> wrote:
> >
> > Greetings,
> >
> > I have been playing around with an RFC proposal for some time and
> recently after discussing it with Tim Düste
,
Ignace Nyamagana Butera
e the `parse`
named constructor ?
On Wed, Apr 30, 2025 at 9:58 AM ignace nyamagana butera
wrote:
> Hi Máté and Tim
>
> I read the following in the RFC
>
> >Withers of Uri\WhatWg\Url follow the relevant “setter steps” that are
> defined <https://url.spec.whatwg.org/#do
y be thrown if the wrong input is given, no
specially crafted string can make the spec throw unless I have overlooked
it.
On Tue, Apr 29, 2025 at 8:55 PM Tim Düsterhus wrote:
> Hi
>
> On 4/29/25 10:54, ignace nyamagana butera wrote:
> > I have one last question while reviewing m
s just
one aspect or URI consumption, we still need scheme specific validation
that only PHP userland package can offer.
Best regards,
Ignace Nyamagana Butera
On Tue, Apr 29, 2025 at 3:55 PM Paul M. Jones wrote:
> Hi Ignace & Maté and all,
>
> tl;dr: I argue against Ignace's object
ant a paragraph in the RFC ? That I
do not know but I feel the question may be raised ?
Best regards,
Ignace Nyamagana Butera
On Mon, Apr 28, 2025 at 11:31 PM ignace nyamagana butera <
nyamsp...@gmail.com> wrote:
> Hi Maté,
>
> > I fiddled a little bit with the implementation, an
Hi Maté,
> I fiddled a little bit with the implementation, and I went with the
Uri\UriComparisonMode enum name at last. I hope that it is OK on your side.
If no one objects with your name choice I am fine with it, as long as it is
not a boolean :) I will adapt my polyfill. I think I have no more
quot;Comfort and the fear of change are the greatest enemies of success."
Best regards,
Ignace Nyamagana Butera
On Mon, Apr 28, 2025 at 9:53 PM Paul M. Jones wrote:
> Hi Maté and all,
>
> > On Apr 27, 2025, at 16:47, Máté Kocsis wrote:
> >
> > Hi Tim,
> ...
&
On Mon, Apr 28, 2025 at 9:05 AM ignace nyamagana butera
wrote:
> Hi Maté,
>
> I found another typo in the RFC examples due to the use of boolean as
> parameters
>
> // The fragment component of Uri\WhatWg\Url can also be taken into
> account$url = new Uri\WhatWg\Url(&qu
), true); // false
The $excludeFragment is `true` by default so in the example it should be
`false` instead. Perhaps using an Enum instead would make the
DX easier than using a boolean ?
I believe the same issue is in all examples regarding the use of that
parameter.
Best regards,
Ignace Nyamagana
Le dim. 27 avr. 2025, 22:32, Tim Düsterhus a écrit :
> Hi
>
> On 4/27/25 22:30, ignace nyamagana butera wrote:
> > $url = Uri\WhatWg\Url::parse("/foo", ".com"); //
> > Throws Uri\WhatWg\InvalidUrlException because of $baseUri
> >
&
Hi Maté
I see you updated the RFC but I believe there's still some errors in the
example:
$url = Uri\WhatWg\Url::parse("/foo", ".com"); //
Throws Uri\WhatWg\InvalidUrlException because of $baseUri
Since parse is used shouldn't it return null instead of throwing ?
$uri =
Uri\Rfc
I still have one last question regarding the RFC3986 URI path component.
Currently the path is nullable but according to the RFC the path can not be
nullable
According to the RFC the path can have up to 5 ABNF representation
> path = path-abempty ; begins with "/" or is empty
ethod is IMHO not helping.
And probably it may ease even your implementation since you would not
have to worry about more edge cases.
Best regards,
Ignace Nyamagana Butera
probably most PHP developers expect this not to fail.
IMHO I am in favor of it failing to get a consistent experience when using the
class because
otherwse you introduce an inconsistency between the constructor behaviour and
the rest of the class
API.
Best regards,
Ignace Nyamagana Butera
On 30/03/2025 22:53, Ignace Nyamagana Butera wrote:
On 30/03/2025 14:42, Tim Düsterhus wrote:
Hi
Am 2025-03-27 23:49, schrieb Ignace Nyamagana Butera:
Hi Máté,
for RFC 3986:
https://datatracker.ietf.org/doc/html/rfc3986#section-5.3), and then
this string is parsed and validated
On 30/03/2025 14:42, Tim Düsterhus wrote:
Hi
Am 2025-03-27 23:49, schrieb Ignace Nyamagana Butera:
Hi Máté,
for RFC 3986:
https://datatracker.ietf.org/doc/html/rfc3986#section-5.3), and then
this string is parsed and validated. Unfortunately, I recently
realized that this approach
On 27/03/2025 22:04, Máté Kocsis wrote:
Hi Ignace,
While implementing the polyfill I am finding easier DX wise to
make the constructor private and use instead named constructors
for instantiation. I would be in favor of
`Uri::parse` and `Uri::tryParse` like it is done currently
On 17/03/2025 20:58, Máté Kocsis wrote:
Hi Ignace,
1) around `Uri\UninitializedUriException` If I look at the
behaviour of
`DatetimeImmutable` in the same scenario or a Userland object
instead of
throwing an exception an error is thrown
see:
- https://3v4l.org/d4Vr
On 14/03/2025 20:45, Máté Kocsis wrote:
Hi Ignace,
> All URI components - with the exception of the host - can be
retrieved in two formats:
I believe you mean - with the excepotion of the Port
Even though I specifically meant WHATWG's host that is only available in
only
one for
On 24/02/2025 12:08, Nicolas Grekas wrote:
Hi,
Thanks for all the efforts making this RFC happen, it'll be a game
changer in the domain!
I'm seeing a push to make the classes final. Please don't!
This would badly break the open/closed principle to me.
When shipping a new class, one ships two
On 25/02/2025 13:36, Paul M.Jones wrote:
Hi there,
On Feb 24, 2025, at 03:36, Tim Düsterhus wrote:
...
but had a look at the “after-action summary” thread and specifically Côme’s
response, which you apparently agreed with:
My take on that is more that functionality in core needs to be «
On 21/02/2025 13:06, Tim Düsterhus wrote:
Hi
Am 2025-02-16 23:01, schrieb Máté Kocsis:
I only harp on the WhatWG spec so much because for many people this
will
be the only one they are aware of, if they are aware of any spec at
all,
and this is a sizable vector of attack targeting servers fro
On 03/01/2025 08:18, Dennis Snell wrote:
It seems that I’ve mucked up the mailing list again by deleting an old message
I intended on replying to. Apologies all around for replying to an older
message of my own.
Máté, thanks for your continued work on the URL parsing RFC. I’m only no
returning
On 28/12/2024 14:42, Máté Kocsis wrote:
Hi Ignace,
Thank you for your efforts!
Specifically for RFC3986Uri I see that the only difference between
the `parse` named constructor and the constructor is that the former
will return `null` instead of throwing an exception. But it is not
Hi Maté,
I finally got the time to review the proposed API and I did some experiments
using a PHP userland polyfill for RFC3986Uri to test the water and to see if I
did understood everything.
First thing first, the API is really well thought and at least for me and my
League/Uri package it is
> Hi Máté
>
> Something that I thought about lately is how the existing URL parser in
PHP is used in various different places.
> So for example, in the http fopen wrapper or in the filter extension we
rely on the built-in URL parser.
> I think it would be beneficial if a URL parser was "pluggable"
On 15/07/2024 11:20, Máté Kocsis wrote:
Hey Ignace, Nicolas,
Based on your request for adding support for RFC 3986 spec compatible
parsing,
I evaluated another library (https://github.com/uriparser/uriparser/)
in the recent days
in order to add support for the requested functionality. As far
Hi Máté,
> Supporting IANA registered schemes is a valid request, and is
definitely useful. However, I think this feature is not strictly
required to have in the current RFC.
True. Having a WHATWG compliant parser in PHP source code is a big +1
from me I have nothing against that inclusion.
On 29/06/2024 11:57, Stephen Reay wrote:
On 29 Jun 2024, at 04:48, Niels Dossche wrote:
- It's a bit of a shame that the PSR interface treats queries as strings.
In Javascript we have the URLSearchParams class that we can use as a key-value
storage for query parameters.
This Javascript clas
Hi Kamil Tekiela,
I read your RFC and I understand the intent in improving the current
parse_str function behaviour by introducing a new function to
avoid possible breakage,
However I feel that we are missing a chance to also improve how parse_str
algorithm is currently used, we could or should (?
As a library maintainer I agree with Stanislav Malyshev . I'm currently
working on a polyfill in League\Csv to enable usage of the empty string
with the escape character. While providing such feature is straightforward
for the insertion part, doing the same for the reading part in quite
complex be
Does adding new methods to SplFileObject easier ? It would mean adding a
getMetaData() (to return stream_get_meta_data infos) method and
(append/prepend/remove)Filter methods to add stream filters API.
On Tue, Oct 3, 2017 at 5:21 PM, Sara Golemon wrote:
> On Tue, Oct 3, 2017 at 9:44 AM, Dan Ac
43 matches
Mail list logo
