On Fri, Oct 7, 2016 at 8:32 AM, David Walker <d...@mudsite.com> wrote:
> On Thu, Oct 6, 2016 at 10:13 PM Stephen Reay <php-li...@koalephant.com> > 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 users > 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/
