[Uri] Add QueryHelpers type

[NinoFloris]

Today we have UriBuilder accepting a string through UriBuilder().Query however as far as I know there are no tools in the framework to help you build such a string.

Now if you do this as a literal it's fairly easy to prove correct but when dynamically building it you have to be mindful that query string keys and values should be properly escaped.

Under the AspNetCore namespace there's QueryHelpers https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.webutilities.queryhelpers?view=aspnetcore-3.1
I would have expected something like this to be built in. It's after all an http-centric world we live in.

EDIT: Hmm apparently System.Web.HttpUtility is actually available on .net core (even though System.Web itself isn't) though it seems to have bugs and isn't really modern.

Related #31147 which was closed as a duplicate of #29736 though I see no mention of query string apis in the latter issue.

It seems to be time to create new modern http url manipulation apis.

To clarify, I wouldn't want to have to reference AspNetCore as a framework reference in libraries.

[scalablecory]

CC @MihaZupan

[davidsh]

@GrabYourPitchforks

[GrabYourPitchforks]

So, as a strawman, a QueryStringBuilder type that's kind of like a Dictionary<string, string> but whose ToString() output is "?key1=value1&key2=value2&..."?

[NinoFloris]

Yes! Though not to forget methods for parsing a query string as well.

Icing on the cake would be designing it to be used without needing to allocate a bunch of tiny strings.

Aside:
System.Uri/Builder is already plenty allocatey. It too could use a refresh, exposing more of its functionality via static methods. Primarily I miss light weight ways of interrogating urls for simple facts like IsDefaultPort, IsLoopback, Scheme ad-hoc parsing usually results in bugs.

[davidfowl]

cc @Tratcher

[GrabYourPitchforks]

I don't know if we would worry too much right now about a proposed QueryBuilder being allocate-y. If this is intended to be a simple API for users to call with minimal effort and minimal ceremony around the call sites, a simple Dictionary<string, string>-like type is hard to beat in terms of usability and reliability.

Static high-performance APIs on System.Uri to answer the questions you had called out are an interesting idea. If you have a particular list you'd like to see implemented go ahead and open a new issue in this repo so that we can track it separately. Thanks! :)

[am11]

a simple Dictionary<string, string>-like type

Perhaps a Dictionary<string, List<string>>-like type to support arrays: ?foo[]=bar&foo[]=baz.

[scalablecory]

I don't think we would add explicit array support -- they are to my knowledge not a defined feature of URIs, with some platforms recognizing foo=1&foo=2&foo=3 and others using the [] syntax.

We would want to design the API so that users could do either, though.

[am11]

It depends on the given library, how values are bound to the target type, In libraries where foo=x&foo=y is considered as an array foo[]=x&foo[]=y will likely map to two-dimensional arrays.

Though my comment was about having multiple values for a key.

[karelz]

Triage: Sounds reasonable and valuable. It would help us obsolete some of the 'bad' APIs on Uri itself.

[mariusz96]

+1, it is very weird that there's no elegant, built-in way to construct query strings for HttpClient without AspNetCore dependency