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
> >>
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
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
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
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
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
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
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
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
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
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
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
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
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)
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.
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
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
17 matches
Mail list logo