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

On 10/13/2016 10:00 AM, David Walker wrote:

On Mon, Oct 10, 2016 at 1:22 PM Larry Garfield <larry@garfieldtech.com> wrote:

Be aware that a user-space definition for a URL object already exists as part of PSR-7: http://www.php-fig.org/psr/psr-7/#3-5-psr-http-message-uriinterface A core-provided mutable and incompatible object would be problematic. What would be useful would be to have a C-level function (parse_url() or otherwise) that can generate a very well-known and standardized array structure (ie, better than parse_url()s now) that a UriInterface implementation could trivially wrap. Basically, a way to simplify this existing code: https://github.com/zendframework/zend-diactoros/blob/master/src/Uri.php#L435 And move the conditionals and filter*() sub-calls to C. (Right now they play games with regexes and hope.)

Hi Larry, I guess I'm not sure why having a RFC/WHATWG compliant parser would be problematic with regard to PSR-7. It would be the application developers responcibility to take a standardized output and populate their object that implements UriInterface. WHATWG does seem to mitigate the need of some of the filter*() calls, but certain ones would still desire to be application-specific. Although WHATWG does not specify that the URL object has a getAll()-esque method, it could be beneficial to have something that returns a structure similar to what parse_url() does today. It could also be beneficial to just have URL implement ArrayAccess so you wouldn't have to bother with getting a specific array back, and can just access what you need. -- Dave

It's not that having an RFC-compliant parser in C is problematic. Quite the opposite. It's the representation it produces back to user-land code. Viz, right now the most common PSR-7 implementation uses parse_url() internally, which as noted is somewhat buggy and incomplete. If PHP natively provided a better parser that a PSR-7 implementation could use, that's good for everyone. What would not be helpful is for PHP to natively provide, essentially, a competitor to PSR-7's Uri object. The raw data parsing can/should live in C, while the main user-space representation is defined in user-space. That's the same point that was made for HTTP headers overall a while back; PHP already has the ability in C to read a stream and parse it out into headers, a GET array, a POST array, etc. It uses it for the super-globals. Exposing that capability to user-space would allow for more efficient and flexible implementations of PSR-7 or similar. I fully expect that in a few years PSR-7 will be updated and supplanted with something that leverages newer PHP features, and we would want to make that transition as smooth as possible. That means having a clear stack of complementary functionality, not competing "polished" functionality that would then have to be mapped back and forth in a clumsy fashion. --Larry Garfield