[RFC] Bug #72811 - Replacing parse_url()

> * 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.

> Hi Nikita, > > On Fri, Oct 7, 2016 at 4:37 AM Nikita Popov <nikita.ppv@gmail.com> wrote: > > > 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. > > > > I was not. I assume that WHATWG ought to supersede the IETF standards on > the subject. I can obviously make an implementation follow the standards > and algorithms set out in this doc. > > 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. > > > > Duly noted. > > > > 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. > > > > If we go the route of making URL it's own object, and expose an > object-oriented interface, are we leading it to be more of a total URL > builder, of sorts? Like: > > $url = new URL(); > $url->setScheme('http'); > $url->setHost('example.org'); > $url->setPath('/test.php'); > var_dump($url->build()); // outputs: http://example.org/test.php > > OR, would it, at the end of the day be an object that takes a string, and > you just call getter's on it that would be akin to the current flags you > pass into parse_url()? > > On both accounts, if we're to go forward with the Object model of URL, > would this want to be broken into it's own ext/url module, like how date > exists? Or retain it in ext/standard? > > Cheers > -- > Dave >

>> 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. >> > If we go the route of making URL it's own object, and expose an > object-oriented interface, are we leading it to be more of a total URL > builder, of sorts? Like: > > $url = new URL(); > $url->setScheme('http'); > $url->setHost('example.org'); > $url->setPath('/test.php'); > var_dump($url->build()); // outputs: http://example.org/test.php > > OR, would it, at the end of the day be an object that takes a string, and > you just call getter's on it that would be akin to the current flags you > pass into parse_url()? > > On both accounts, if we're to go forward with the Object model of URL, > would this want to be broken into it's own ext/url module, like how date > exists? Or retain it in ext/standard? > > Cheers > -- > Dave

> On Fri, Oct 7, 2016 at 4:37 AM Nikita Popov <nikita.ppv@gmail.com> wrote: > >> 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. > > I was not. I assume that WHATWG ought to supersede the IETF standards on > the subject. I can obviously make an implementation follow the standards > and algorithms set out in this doc.