Re: [RFC] [Discussion] Followup Improvements for ext/uri

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é