Rust query string parser with nesting support

The Serde update breaks its API, introducing a wrapper around the previous type alias for a BTreeMap. It also updates to_value to return a Result instead of a Value directly. I've updated the uses of BTreeMap to refer to the new Map struct instead, and added a .expect to the use of to_value - I don't think there's any reason it should fail, since our data is definitely serializable, but let me know if you'd prefer a different technique there.

This is a breaking change, since it requires users of queryst to update their serde_json.

In a number of query-string parsing and serialization environments there is ambiguity about the intent and meaning of ?a= vs ?a.

The URI RFC allows for both inside URIs, and does not specify behaviour. Many environments choose to have both null/none/empty and also empty-string values serialize to a=.

This can lead to ambiguity and in some cases it could be useful to reliably parse null/none/empty values back from a query-string (a), while retaining the ability to parse empty strings (a=).

This pull request is a work-in-progress; I'd like to resolve the following:

• [ ] Backwards-compatibility: ideally the existing behaviour should be maintained for prior library versions; in other words, unless requested otherwise, a None match for a value should return an empty string unless the caller opts-in for None result value parsing

I am trying to (ab)use this library to parse attributes in the path component of PKCS11 URIs (RFC 7512), which use semicolon delimiters (in the query component, the usual ampersand delimiters are used). I honestly don't know where this comes from, maybe the obsolete RFC 1866 which mentions accepting both semicolons and ampersands.

What do you think about this? I'd completely understand if you think such a feature is out of scope.

This change eliminates a compile-time lint warning; the indicated try! macro is removed, and an ? operator is introduced instead.

warning: use of deprecated item 'try': use the `?` operator instead
   --> src/parser.rs:179:29
    |
179 |         let parse_key_res = try!(parse_key(key));

Hello,

i have an input filed which should be send to the server for filtering which can be entered by an user. when he types some words+ (a little contrieved, i know, but still possible) Google Chrome generates the following request to the server: https://server/api/endpoint?filter%5Bquery%5D=some+words%2B&page%5Bsize%5D=100 Which looks fine to me. When parsing the querystring it gives the following result: Ok(Object({"filter": Object({"query": String("some+words+")}), "page": Object({"size": String("100")})}))

In this Object the real plus is indistinguishable from the plus as space character.

This probably stems from first calling url::percent_decode and then using its own parse_pairs instead of directly using https://docs.rs/url/1.7.2/url/struct.Url.html#method.query_pairs

I try an create a failing test in a PR and fix the problem later.

(There apparently is a difference between decoding a url and getting the query_params as pairs which has to do with if the parser is in urlformdecode mode or not. Don't Ask me)

Hello there!

This MR updates the dependencies of the crate to their most recent versions, it also adds an include attribute based on the suggestions of the cargo-diet command.

It points to https://travis-ci.org/github/lord/queryst-prime not https://travis-ci.org/github/s-panferov/queryst and the latter doesn't appear to be enabled yet.