Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96287
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <45EED5CC-BFEE-4CB3-83A5-35D8601707DE@koalephant.com>
References: <CADVQu1QYkLGowNGVohfRvYWc=8N7tWfcjghOT0Zvx0_PuJSDYw@mail.gmail.com>
 <CAF+90c_otDn4V3AjsSPMbKg4mBcX5PT3B-Y97hEBqANThcksVg@mail.gmail.com> <45EED5CC-BFEE-4CB3-83A5-35D8601707DE@koalephant.com>
Date: Fri, 7 Oct 2016 15:58:06 +0200
Message-ID: <CAF+90c_KdGMCqW-ShK0R1c0SqRf8OZHZTfjQ0CX4MazwheaNPQ@mail.gmail.com>
To: Stephen Reay <stephen@koalephant.com>
Cc: David Walker <dave@mudsite.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c19a4f0bcfb83053e46cc4f
Subject: Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c19a4f0bcfb83053e46cc4f
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 7, 2016 at 2:22 PM, Stephen Reay <stephen@koalephant.com> wrote:

> I think adopting the JavaScript model here is not an improvement.
>
> One of the strengths of parse_url is that it can parse a partial url and
> give the parts that are found. How do we achieve the same using the whatwg
> concept where relative URLs *require* a base url, besides using
> fake://fakey.mcfakeface/fakes?faking#faker as the base url?
>

This strength of parse_url is also its weakness. In the FastRoute README I
used to recommend that people use parse_url() to extract the path component
of REQUEST_URI. It turns out that while this works for 99% of URLs it will
fail in specific edge-cases, such as paths starting with more than one
slash. To get correct behavior you either need to strip the query string
yourself, or use parse_url() with an artificial prefix (which is the
equivalent of your suggestion).


> Also, the browser implementations specifically *dont* handle parsing of
> the query string into a usable structure. So would we then need to create a
> url object and pass it's query property to parse_str to get a useful value?
>

parse_url() doesn't handle this either. For the record, the URL spec does
handle this in the form of URLSearchParams, but this is likely not directly
transferable to PHP, because PHP interprets query strings differently.


> I'm not against OO, I would just rather that if it goes that way, a solid
> implementation is used, because simply copying what's used in JavaScript
> sounds like a decision that will be regretted down the track.
>

To be clear, the URL API is not some legacy API that JS is stuck with for
historic reasons. It's a relatively new addition to the point that MDN
marks it as "experimental". I'm not saying that it's necessarily best to
directly copy it (I'm not sufficiently familiar with the subject matter),
but I do suspect that they have put significantly more thought into this
than we have.

Nikita

--94eb2c19a4f0bcfb83053e46cc4f--