Add support for passing list[tuple[str, object]] to data

[RobertCraigie]

I have to make a multipart/form-data request that includes nested objects. My current solution is to preprocess the field names such that they can be correctly deserialised by the server, e.g. {'foo': {'bar': ...} turns into the key: foo[bar].

While this solution works for most cases, it does not work for arrays as the format that the server uses looks like this: documents[][foo] which means the keys have to be duplicated for each entry in the array. This is not currently possible to support as httpx expects a dictionary to be passed to data. Supporting passing a list of two tuples, like params does would make this possible.

I'm happy to put up a PR for this if necessary :)

[adriangb]

As far as I know there is no standard way to serialize nested objects in multipart/form-data requests. What you are describing corresponds to what Swagger/OpenAPI calls the "deepObject" serialization method: https://swagger.io/docs/specification/serialization/.

The multipart/form-data spec only states that fields may be singular or repeated. You can send a repeated field like: httpx.post(..., data={"documents": ["doc1", "doc2"], files=...). This will result in "duplicate" data being transmitted. You could also do something like httpx.post(..., data={"documents": json.dumps( ["doc1", "doc2"]), files=...) in which case there's no duplicate data but the server has to know that the field is JSON.

[falkben]

I wonder if this should be mentioned in the Requests Compatibility page, as requests will do the tuple unpacking. https://requests.readthedocs.io/en/latest/api/#requests.request

If so desired, I could try to add a documentation PR for that?

[tomchristie]

as requests will do the tuple unpacking

Could you provide an example of the difference in behaviour?

[falkben]

The second example here https://requests.readthedocs.io/en/latest/user/quickstart/#more-complicated-post-requests

[tomchristie]

Ah, gotcha. Yes I'd be okay with a note on that.

I'd suggest something like a "Nested Data" note, following the note on None values in "Query Parameters". They seem like somewhat similar cases to me.

[falkben]

I've made a PR to add a note about this: #2461

[mikenerone]

I'm just mentioning that this discussion conflates two different things: OP phrasing asked for nesting dictionaries in data ("{'foo': {'bar': ...}"), which the standards indeed do not cover, but the referenced feature in requests isn't that, it's just passing all of the keys and values in the form [("k1", "v1"), ("k2", "v2"), ...], which is a much easier thing to implement. IMO, it should be supported, because whether standards-compliant or not, some servers treat the key order in the form post as significant. I'm dealing with one right now that has duplicate keys and where they appear in the payload is significant. My only solution with httpx right now is to manually build the form POST payload myself.

[tomchristie]

Key ordering is preserved...

>>> httpx.Request('GET', 'https://www.example.com', data={'a': '123', 'b': '456'}).content
b'a=123&b=456'
>>> httpx.Request('GET', 'https://www.example.com', data={'b': '456', 'a': '123'}).content
b'b=456&a=123'

that has duplicate keys and where they appear in the payload is significant

True, we don't support eg. "b=456&a=123&b=789".

My only solution with httpx right now is to manually build the form POST payload myself.

I guess that's what I'd do as well...

content = urllib.parse.urlencode([("b", "456"), ("a", "123"), ("b", "789")])
headers = {
    "Content-Type": "application/x-www-form-urlencoded",
    "Content-Length": str(len(content))
}