DataField.render_data fails when value is not string about httpx HOT 13 CLOSED

Okay. Multipart encoded data can only handle string or File data. We could perfectly well either coerce a limited set of scalar types, or just coerce any inputs with str()

from httpx.

Would probably be a useful point of reference to stay in line with whatever urllib3 currently does.

from httpx.

https://github.com/urllib3/urllib3/blob/master/src/urllib3/filepost.py#L84-L90

urllib3 isn't doing anything particularly advanced either. i can make a PR with a similar solution if you are fine with it.

from httpx.

So looks like urllib3 only accepts str/byte values. What does requests do for that case? If it coerces to str, then any idea where it does that?

from httpx.

Most of the fiddly magic in requests happens in requests.models:_encode_files. Quite a bit of knowledge implemented which can help us. Prepared data is then sent to urllib.filepost:encode_multipart_formdata we've already checked above.

Another edge case i came across reading this code are None values in data which would have to be handled in http3.multipart:multipart_encode

from httpx.

Okay, so to keep in the with the behaviour I can see there, we should:

• Ignore None values.
• Cast any non-str/bytes to str.
• Handle lists of args.

from httpx.

I already posted in the PR (didn't realize this was the issue for that PR until looking further down the list) but I'm not a fan of blindly casting objects that are passed in to strings and then shipping that. Why not raise an error in that situation?

from httpx.

my argument would be that data ends up as string in multipart form body anyway and interface should let user go as far as reasonably possible before raising errors.

from httpx.

There's no right answer here - either API could be an resonable design choice.

I think we should probably prefer to nail things down quite tightly - given that we've got properly typed interfaces all the way through, it'd be nice if we worked towards raising TypeError on any incorrect type passed to one of our public interfaces.

from httpx.

We should strive towards no typing.Any usage in public interfaces. :)

from httpx.

Does this imply this issue is a non-issue then? It already works as expected under current implementation. Should libraries using http3 convert passed values in data dict according to interface?

from httpx.

I guess there's still some issues to be resolved here:

• Ensure we deal with list of str / list of bytes okay.
• Ensure we raise TypeError on any dict values other than bytes|str|typing.List[bytes]|typing.List[str].
• Ensure we raise TypeError on any dict keys other than str.

Slightly depends on exactly which points we intend to perform the type checking at.

from httpx.

Can this issue be closed now?

from httpx.