Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96283
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADVQu1QYkLGowNGVohfRvYWc=8N7tWfcjghOT0Zvx0_PuJSDYw@mail.gmail.com>
References: <CADVQu1QYkLGowNGVohfRvYWc=8N7tWfcjghOT0Zvx0_PuJSDYw@mail.gmail.com>
Date: Fri, 7 Oct 2016 12:37:23 +0200
Message-ID: <CAF+90c_otDn4V3AjsSPMbKg4mBcX5PT3B-Y97hEBqANThcksVg@mail.gmail.com>
To: David Walker <dave@mudsite.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113f453ceb296f053e43fec2
Subject: Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()
From: nikita.ppv@gmail.com (Nikita Popov)

--001a113f453ceb296f053e43fec2
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 4, 2016 at 8:14 PM, David Walker <dave@mudsite.com> 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 scope of
> how parse_url() was processing URI's.  After opening a PR for the
> resoution, Yasuo and Christoph both chimed in that perhaps replacing the
> implementation with an re2c based parser would be better.  We found a
> parser[2] that did almost everything necessary.  I took it and made it more
> strictly adhere to RFC3986[3].
>
> I have updated my original PR[4] and created a RFC[5] that aims to replace
> the parsing of parse_url() to be more strict to RFC3986.  This will provide
> a BC break, as explained in the RFC that at very least warrants some
> discussion.  We had kicked around the idea on the PR of deprecating
> parse_url, and creating a new function with the more-compliant parser, but
> oped against it.
>
> I'm looking for discussion on if a total replacement is the preferred way
> to go about this, and if, we should be making parse_url() more standards
> strict.  Since it today has many breaks with RFC3986 that provide
> semi-reasonable parsing patterns.
>
> --
> Dave
>
> [1] - https://bugs.php.net/bug.php?id=72811
> [2] - https://github.com/staskobzar/url_parser_re2c
> [3] - https://tools.ietf.org/html/rfc3986
> [4] - https://github.com/php/php-src/pull/2079
> [5] - https://wiki.php.net/rfc/replace_parse_url
>

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 "illegal" code points,
query encoding, equality, canonicalization, are all concepts not entirely
shared, or defined.) URL parsing needs to become as solid as HTML parsing.

Basically this is the standard that describes how URL parsing actually
works in the wild, in browser implementations. In particular it also
includes a description of URL parsing in algorithmic form, including
specific directions as to which errors are fatal and which are not.

Also quoting from the goals:

> Standardize on the term URL. URI and IRI are just confusing. In practice
a single algorithm is used for both so keeping them distinct is not helping
anyone. URL also easily wins the search result popularity contest.

For this reason, I would recommend against introducing the term "URI"
anywhere. In particular the suggestion from this thread to use parse_uri()
for this functionality seems like it will cause a lot of confusion.

The URL standard also specifies the interface of the URL object used by
JavaScript and I think we should consider whether we may want to simply
adopt this (object-oriented) interface (potentially with adjustments for
PHP specifics).

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 of sense and I think it makes it
much clearer how "incomplete" URLs are being treated.

While we're at it, what's the state of IDN? May this be the time to
properly support it?

Nikita

 [1]: https://url.spec.whatwg.org/

--001a113f453ceb296f053e43fec2--