Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96343
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain mudsite.com designates 209.85.215.44 as permitted sender)
MIME-Version: 1.0
References: <CADVQu1QYkLGowNGVohfRvYWc=8N7tWfcjghOT0Zvx0_PuJSDYw@mail.gmail.com>
 <CAF+90c_otDn4V3AjsSPMbKg4mBcX5PT3B-Y97hEBqANThcksVg@mail.gmail.com>
 <CADVQu1SB4f2fivmjHZLLXPkEQaprrLe8rQoRm3Ln2QgtrC=xDA@mail.gmail.com> <6c571887-c24f-0f11-26b0-5f67b5e7a170@gmx.de>
In-Reply-To: <6c571887-c24f-0f11-26b0-5f67b5e7a170@gmx.de>
Date: Thu, 13 Oct 2016 17:08:27 +0000
Message-ID: <CADVQu1QNZPio3XANb6GKEpTMOA+7RR3ndRoHpuEVzUGJCTKzGw@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>, Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c0db56423d090053ec22944
Subject: Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()
From: dave@mudsite.com (David Walker)

--94eb2c0db56423d090053ec22944
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 13, 2016 at 10:54 AM Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> On 07.10.2016 at 16:45, David Walker wrote:
>
> > 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.
>
> 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.
>

We could say that we support WHATWG@f88f96 and support the previous 2, or
3, keeping in line with some BC ability.  But yes, it would be a nuisance
and overly complex to keep updating the parser for frivolous changes (like
that commit) which re-makes fragments an optional part of a URL.

I'd be more apt to stick to a single 3987/3988 compatible parser, which
ought to be future compatible with WHATWG.  It would just lack any of the
standardization terms, object models, and rigid-parser definitions.  That's
to say that WHATWG maintains the requirements of the 2RFC and just expands
on them.

This also plays with what Larry is saying by keeping the parsing, and
object-side of things separate.  WHATWG does have a very nice layout of the
URL/SearchParams, and how they can play with eachother.  I'd think that end
of the spec should be left for userland classes, in the event a new PSR
wants to propose implementing the WHATWG format of URL/SearchParams/Hosts,
etc.

--
Dave

--94eb2c0db56423d090053ec22944--