Hi,
The WHATWG URL living standard does the following:
>
> let url = new URL('https://example.com?debug&foo=bar&debug=');
> console.log(
> url.searchParams.toString(), //returns debug=&foo=bar&debug='
> );
>
> the pair gets converted to ['debug' => '']. The roundtrip does not
> conserve the query string as is but all key/pair (tuples) are present.
>
Yes, confirmed. Unfortunately, WHATWG URL only supports string values, so
there's no way to support
query parameters without a key (e.g. ?debug) in the RFC implementation
either. :(
On the other hand, the RFC 3986 implementation supports this notion, even
uriparser calls this out
in its documentation:
https://uriparser.github.io/doc/api/latest/index.html#querystrings.
However, there are a few other problems which came up when I was updating
my implementation.
1.) Yesterday, I wrote that name mangling of the query params shouldn't
happen. However, as I realized,
it is still needed for non-list arrays, because the [..] suffix must be
added to their name:
$params = new Uri\Rfc3986\UriQueryParams()
->append("foo", [2 => "bar", 4 => "baz"]);
echo $params->toRfc3986String(); //
foo%5B2%5D=bar&foo%5B4%5D=baz
var_dump($params->getFirst("foo")); // NULL
Even though I appended params with the name "foo", no items can be returned
when calling getFirst(),
because of name mangling.
2.) I'm not really sure how empty arrays should be represented? PHP doesn't
retain them, and they are
simply skipped. But should we do the same thing? I can't really come up
with any other sensible behavior.
$params = new Uri\Rfc3986\UriQueryParams()
->append("foo", []);
echo $params->toRfc3986String(); // ???
3.) We wrote earlier that objects shouldn't be supported when creating
the query string from variables. But what about
backed enums? Support for them in http_build_query() was added not long
ago: https://github.com/php/php-src/pull/15650
Should we support them, right?
Regards,
Máté
