Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96277 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 87065 invoked from network); 7 Oct 2016 04:13:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Oct 2016 04:13:12 -0000 Authentication-Results: pb1.pair.com smtp.mail=php-lists@koalephant.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=php-lists@koalephant.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain koalephant.com designates 206.123.115.54 as permitted sender) X-PHP-List-Original-Sender: php-lists@koalephant.com X-Host-Fingerprint: 206.123.115.54 mail1.25mail.st Received: from [206.123.115.54] ([206.123.115.54:39247] helo=mail1.25mail.st) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1F/63-23443-6D027F75 for ; Fri, 07 Oct 2016 00:13:12 -0400 Received: from [10.0.1.23] (unknown [183.89.105.36]) by mail1.25mail.st (Postfix) with ESMTPSA id 9670A6049F; Fri, 7 Oct 2016 04:12:58 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) In-Reply-To: Date: Fri, 7 Oct 2016 11:13:34 +0700 Cc: "Christoph M. Becker" , PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: References: To: David Walker X-Mailer: Apple Mail (2.3124) Subject: Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url() From: php-lists@koalephant.com (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 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=20 > On 7 Oct 2016, at 01:10, David Walker wrote: >=20 > On Thu, Oct 6, 2016 at 11:19 AM Christoph M. Becker = > wrote: >=20 > So, I basically see two options: >=20 > * wait until PHP 8 (whenever that'll be released) and switch the > implementation of parse_url() then =E2=80=93 what might delay the = adoption > of PHP 8 >=20 > * add a new function in PHP 7.2 (maybe called parse_uri()), and > perhaps deprecate parse_url() at the same time >=20 >=20 > 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. >=20 > 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() >=20 > * 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) >=20 > 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. >=20 > -- > Dave