[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 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

Hi David,

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

+1

Current URL parse code is not maintainable, not standard compliant as well.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

I'd suggest URL to be immutable and have a URLBuilder (obtainable through
URL::createBuilder()) for that...

Hi Nikita,

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

--
Guilherme Blanco
Lead Architect at E-Block

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

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

--Larry Garfield

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.

That might be hard, because WHATWG has "living standards", i.e. they can
change over time. If we state that our new functionality conforms to
WHATWG's URL standard we have to always apply the latest changes even
into revisions, potentially causing BC breaks.

--
Christoph M. Becker