Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-13 Thread David Walker
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 > >>

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-13 Thread Christoph M. Becker
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

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-13 Thread Larry Garfield
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

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-13 Thread David Walker
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

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-10 Thread Larry Garfield
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

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-07 Thread guilhermebla...@gmail.com
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

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-07 Thread David Walker
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

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-07 Thread Nikita Popov
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

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-07 Thread Michał Brzuchalski
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

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-07 Thread 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 working

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-07 Thread Nikita Popov
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

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-07 Thread Michał Brzuchalski
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

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-07 Thread 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 Hostnames. It was also going to parse query arguments

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-07 Thread Marco Pivetta
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)

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-07 Thread David Walker
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.

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-06 Thread Stephen Reay
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

[PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

2016-10-04 Thread David Walker
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