Add function to `Uri` and `PathAndQuery` to return parsed map of query parameters

[xumaple]

As the crate that provides all http-related types, I find it odd that we offload the parsing of query parameters to users.

Suggestion is a simple function which parses the query and returns it as a HashMap of keys/vals:

pub fn query_params(&self) -> &HashMap<&str, &str> { todo!() }

[robjtede]

Unfortunately, a querystring represents a multi-map. So it would have to be: -> HashMap<&str, Vec<&str>>. This has come up before and I still don't belive that querystring handling should be part of the http crate.

You should rely on other crates for such tasks, see any of:

• serde_urlencoded
• serde_qs
• serde_html_form

[xumaple]

Even with the extra complexity of a multi-map, this is still a <10 line functionality.

What is your reasoning behind not allowing this handling into the http crate? It is, after all, a deserialization process, which is already very much ingrained in the crate's workflows/purposes?

[robjtede]

The functionality exists in other crates to do this, and do it well. Flexible. With options for 0 allocations via serde. Implementing it here without offering that flexibility would simply be a worse experience than pointing to those crates.

It's likely more than a 10 line change to do correctly. Though if your use case doesn't need to handle edge cases then you can just add the 10-line, simplistic version in your project, right?

[seanmonstar]

I agree with Rob. Another reason it's not in http is that there are different ways to interpret the query parameters, especially when it comes to "lists". Some deserializers may turn foo=one&foo=two into foo: [one, two], while others require it to look like foo[]=one&foo[]=two.