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

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 related RFC is published, do we get a third function?) 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. Thanks for all you do guys! Cheers Stephen > On 7 Oct 2016, at 01:10, David Walker <dave@mudsite.com> wrote: > > On Thu, Oct 6, 2016 at 11:19 AM Christoph M. Becker <cmbecker69@gmx.de> > wrote: > > So, I basically see two options: > > * wait until PHP 8 (whenever that'll be released) and switch the > implementation of parse_url() then – what might delay the adoption > of PHP 8 > > * add a new function in PHP 7.2 (maybe called parse_uri()), and > perhaps deprecate parse_url() at the same time > > > I'd probably side more with the former, but as a hybrid? As a stickler for > naming parse_url() also seems to parses URN's correctly. imo, the proper > name would be parse_uri() for something that can correctly parse any URI > per the RFC. > > Would it be plausible to blend the options by [sorry if this is a faux pas > I'm not familiar with yet] > * PHP 7.2+ > * Adding parse_uri() as the new RFC compliant parser > * Deprecating the functionality of parse_url() with notice that parser > will change to that of parse_uri() > > * PHP 8.0 > * Alias parse_url() to be parse_uri() > * Deprecate parse_url() for the name (or just let it exist as a alias > forever) > > Obviously having two UR* parsers for the long-term would be a poor option, > this might enable people to migrate to the new name & parser, before PHP 8 > becomes a reality. > > -- > Dave