Serialize Vec<T> about serde_urlencoded

[samscott89]

Hey @nbigaouette, I've created serde_qs to try and fill this gap, since I think the extra functionality needed would be unnecessarily cumbersome to this library.

Let me know if it's suitable for your use case. I showed in the examples how you could also support the comma-separated vector lists (though actually the same strategy would presumably work fine here as well).

[nbigaouette]

To make things more "interesting", I would also need the Vec to be serialized to name=val1,val2,val3,... Would that be possible too?

[nox]

There is no standard for that and not every backend tooling handle such things with brackets. For example some Perl libraries just deserialise multiple entries with the same key as an array, which is why I decided to not support this feature in this crate directly.

[antoine-de]

@lnicola serde_qs handles this, but in non strict mode. I have an example here.

[TeXitoi]

With @antoine-de we don't really understand your temporary allocation.

What we need is:

#[derive(Deserialize, PartialEq)]
struct Params {
    foo: Vec<i32>,
}

assert_eq!(
    serde_urlencoded::from_bytes(b"foo=23&foo=42"),
    Ok(Params { foo: vec![23, 42] })
);

If it's OK for you, we can implement it.

[lnicola]

@samscott89 is serde_qs supposed to handle percent-encoded brackets? s[]=1+2&s[]=2 seems to work, but s%5B%5D=1+2&s%5B%5D=2 doesn't. If I'm not missing anything, that's what browsers send for forms.

@nox serde_urlencoded advertises support for application/x-www-form-urlencoded, but this issue makes that feel misleading.

[samscott89]

For the record, I agree with @nox :)

An alternative potential implementation to unify the various options would follow the swagger/openapi spec: https://swagger.io/docs/specification/serialization/#query

The serde_qs approach roughly corresponds to "deepObject" style for example.

[nox]

It's not currently possible, I've wished to implement it for a while now, will probably look at it next week.

[nox]

I won't support the comma separated thing, but the repeated key name yes.

[antoine-de]

Just to be sure to understand, you don't plan to support the repeated key name ? You suggest serde_qs for this too ?

[nox]

Yes, anything that requires temporary allocation won't be added to this crate.

[nox]

#[derive(Deserialize)]
struct Params {
    foo: Vec<i32>,
    bar: String,
}

serde_urlencoded::from_bytes::<Params>(b"foo=23&bar=baguette&foo=42")

Handling sequences mean traversing the entire string to get all the pairs with the same key, and only then you can deserialise that to a Vec<i32>, I won't accept any such patch in this crate, but AFAIK this kind of thing isn't out of scope for serde_qs.

[samscott89]

Handling sequences mean traversing the entire string to get all the pairs with the same key, and only then you can deserialise that to a Vec, I won't accept any such patch in this crate, but AFAIK this kind of thing isn't out of scope for serde_qs.

Yeah, this is true to the extent of my understanding. The performance of serde_qs is significantly worse than serde_urlencoded due to this, so keeping the separation seems like a good idea to me.

And yes, serde_qs can handle most structs. In the case of vecs, you can either use indexed arrays foo[0]=...&foo[1]=... or unindexed, foo[]=...&foo[]=....

[antoine-de]

ok great @samscott89 , I'll see how to plug serde_qs in actix then.

thanks for your replies @nox , sorry for having bothered you.

[nox]

How is that misleading? application/x-www-form-urlencoded specifically doesn't have any concept of nesting or even serialising a sequence of values. This crate (and url) does handle percent-encoded brackets, as the WHATWG URL Standard says to do it.

[lnicola]

Misleading for someone who wants to use it for something that looks like an array sent by a web browser :-).