Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96281
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain brzuchalski.com designates 188.165.245.118 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADyq6sLWgoAPKTiqLLNVP4ECs15dQSvLKL12tanMfMVhDUYfvg@mail.gmail.com>
References: <CADVQu1QYkLGowNGVohfRvYWc=8N7tWfcjghOT0Zvx0_PuJSDYw@mail.gmail.com>
 <fa578fe5-6069-bc02-253e-ba849215a87a@gmx.de> <CADVQu1S5MDMqZRBovrMM94_=qyLvM5dkH_K4DwQJEx66mKruFQ@mail.gmail.com>
 <F3741613-1E6C-4978-8284-9EB505A46F2A@koalephant.com> <CADVQu1QLUs1PnbFo3=Hh3H3_1i_Hzso82So5WT74wz3jQ+8OLw@mail.gmail.com>
 <CADyq6sLWgoAPKTiqLLNVP4ECs15dQSvLKL12tanMfMVhDUYfvg@mail.gmail.com>
Date: Fri, 7 Oct 2016 11:21:13 +0200
Message-ID: <CABdc3WpA8JQHE=sOWsBiRB0LA=cT1CUUss+6gTKCSkGXyw8+YQ@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: David Walker <dave@mudsite.com>, Stephen Reay <php-lists@koalephant.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1143f70486e21e053e42eefb
Subject: Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--001a1143f70486e21e053e42eefb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 i=
t
maybe not be finished yet but supports parsing URI with IPv4, IPv6 and
Hostnames.
It was also going to parse query arguments from URI depending on how to
parse multiple arguments:
* some languages parses `?arg1=3D1&arg1=3D2` as an array, PHP parses only l=
ast,
* `?arg1[]=3D1&arg1=3D3` some parses adding element 3 to "arg1" array some
replaces)

This implementation also supports UriTemplates ("
http://localhost/{module}/action") and UriReferences
("/some/reference?arg1=3D2#fragment").


2016-10-07 8:38 GMT+02:00 Marco Pivetta <ocramius@gmail.com>:

> On Fri, Oct 7, 2016 at 8:32 AM, David Walker <dave@mudsite.com> wrote:
>
> > On Thu, Oct 6, 2016 at 10:13 PM Stephen Reay <php-lists@koalephant.com>
> > wrote:
> >
> > > Could the new URL parser be exposed via a third parameter to parse_ur=
l,
> > > 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 use=
rs
> > to the previous functionality being non-standards compliant.  Secondly =
it
> > allows the previous parser to exist in it's current state for a longer
> > period of time, then in 8.0 exist as a function parameter.  The goal
> should
> > be to drop the standards-uncompliant version at some point.
> >
> >
> > > Additionally, would(could) this same url parser be used for
> > > FILTER_VALIDATE_URL, which currently states (in the docs) that it
> matches
> > > RFC2396, and indeed it appears not to accept an IPv6 host segment.
> > >
> >
> > I haven't yet looked at to how filter validation exists in conjunction
> with
> > parse_url(), however as noted (
> > http://php.net/manual/en/filter.filters.validate.php#110411) the
> > FILTER_VALIDATE_URL, may be strict to URL's not URN's.  Maybe, a future
> > scope could be to look at filter_var() and how it uses that filter type=
.
> > Maybe could add a proper FILTER_VALIDATE_URI, or something.
> >
> > However that would be outside the scope of this RFC for right now, I
> > believe.
> >
> > --
> > Dave
> >
>
> Like with any software rewrite project, remember that software rewrites
> usually fail.
>
> It's probably better to deprecate the function, make a new one, then code
> the newer implementation there, and let users migrate.
>
> This is necessary to mitigate the risk of BC breaks.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>



--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
brzuchalski.com

--001a1143f70486e21e053e42eefb--