On Thu, Oct 13, 2016 at 10:54 AM Christoph M. Becker
wrote:
> On 07.10.2016 at 16:45, David Walker wrote:
>
> > On Fri, Oct 7, 2016 at 4:37 AM Nikita Popov
> wrote:
> >
> >> Are you aware of the WHATWG URL standard [1]? Quoting the first goal
> >> statement:
> >>
> >>> Align RFC 3986 and RFC 398
On 07.10.2016 at 16:45, David Walker wrote:
> On Fri, Oct 7, 2016 at 4:37 AM Nikita Popov wrote:
>
>> Are you aware of the WHATWG URL standard [1]? Quoting the first goal
>> statement:
>>
>>> Align RFC 3986 and RFC 3987 with contemporary implementations and
>> obsolete them in the process. (E.g.
On 10/13/2016 10:00 AM, David Walker wrote:
On Mon, Oct 10, 2016 at 1:22 PM Larry Garfield
wrote:
Be aware that a user-space definition for a URL object already exists as
part of PSR-7:
http://www.php-fig.org/psr/psr-7/#3-5-psr-http-message-uriinterface
A core-provided mutable and incompatib
On Mon, Oct 10, 2016 at 1:22 PM Larry Garfield
wrote:
> Be aware that a user-space definition for a URL object already exists as
> part of PSR-7:
>
> http://www.php-fig.org/psr/psr-7/#3-5-psr-http-message-uriinterface
>
> A core-provided mutable and incompatible object would be problematic.
>
> W
On 10/07/2016 09:45 AM, David Walker wrote:
I think an important part of this interface is that the URL is constructed
using URL(url [, base]), where "base" is the base URL against which
relative URLs are resolved. This base URL is required for parsing
non-absolute URLs. To me this makes a lot of
I'd suggest URL to be immutable and have a URLBuilder (obtainable through
URL::createBuilder()) for that...
On Fri, Oct 7, 2016 at 10:45 AM, David Walker wrote:
> Hi Nikita,
>
> On Fri, Oct 7, 2016 at 4:37 AM Nikita Popov wrote:
>
> > Are you aware of the WHATWG URL standard [1]? Quoting the fi
Hi Nikita,
On Fri, Oct 7, 2016 at 4:37 AM Nikita Popov wrote:
> Are you aware of the WHATWG URL standard [1]? Quoting the first goal
> statement:
>
> > Align RFC 3986 and RFC 3987 with contemporary implementations and
> obsolete them in the process. (E.g., spaces, other "illegal" code points,
>
On Fri, Oct 7, 2016 at 2:22 PM, Stephen Reay wrote:
> I think adopting the JavaScript model here is not an improvement.
>
> One of the strengths of parse_url is that it can parse a partial url and
> give the parts that are found. How do we achieve the same using the whatwg
> concept where relativ
2016-10-07 12:55 GMT+02:00 Yasuo Ohgaki :
> Hi Michal,
>
> On Fri, Oct 7, 2016 at 6:47 PM, Michał Brzuchalski
> wrote:
> > 2016-10-07 11:21 GMT+02:00 Michał Brzuchalski :
> >
> >> How about complete rewrite with OOP? It could be implemented using
> Objects
> >> like DateTime does.
> >> I've got w
Hi Michal,
On Fri, Oct 7, 2016 at 6:47 PM, Michał Brzuchalski
wrote:
> 2016-10-07 11:21 GMT+02:00 Michał Brzuchalski :
>
>> How about complete rewrite with OOP? It could be implemented using Objects
>> like DateTime does.
>> I've got working implementation in userland https://github.com/madkom/ur
On Tue, Oct 4, 2016 at 8:14 PM, David Walker wrote:
> Hi all,
>
> A couple weeks back I took a look at 72811[1]. The bug being that
> parse_url() didn't accept IPv6 addresses without a scheme, like it did for
> IPv4 addresses. I attempted to patch the specific bug within the scope of
> how pars
2016-10-07 11:21 GMT+02:00 Michał Brzuchalski :
> How about complete rewrite with OOP? It could be implemented using Objects
> like DateTime does.
> I've got working implementation in userland https://github.com/madkom/uri it
> maybe not be finished yet but supports parsing URI with IPv4, IPv6 and
How about complete rewrite with OOP? It could be implemented using Objects
like DateTime does.
I've got working implementation in userland https://github.com/madkom/uri it
maybe not be finished yet but supports parsing URI with IPv4, IPv6 and
Hostnames.
It was also going to parse query arguments fr
On Fri, Oct 7, 2016 at 8:32 AM, David Walker wrote:
> On Thu, Oct 6, 2016 at 10:13 PM Stephen Reay
> wrote:
>
> > Could the new URL parser be exposed via a third parameter to parse_url,
> > which defaults to false/off in 7.2 (or whenever its added) but then
> > defaults to true in 8.0?
>
>
> I,
On Thu, Oct 6, 2016 at 10:13 PM Stephen Reay
wrote:
> Could the new URL parser be exposed via a third parameter to parse_url,
> which defaults to false/off in 7.2 (or whenever its added) but then
> defaults to true in 8.0?
I, personally, would be opposed to this. Firstly, it doesn't alert user
Could the new URL parser be exposed via a third parameter to parse_url, which
defaults to false/off in 7.2 (or whenever its added) but then defaults to true
in 8.0?
Introducing a new core function to effectively fix a bug seems like the wrong
approach to me (and what happens if a new URL/URI re
Hi all,
A couple weeks back I took a look at 72811[1]. The bug being that
parse_url() didn't accept IPv6 addresses without a scheme, like it did for
IPv4 addresses. I attempted to patch the specific bug within the scope of
how parse_url() was processing URI's. After opening a PR for the
resouti
17 matches
Mail list logo