Multipart parser should decode those JSON parts that are flagged as such

[Facundo Batista]

If a part of the multipart body has a proper JSON mimetype, it should be automatically decoded.

Attached is a proof of concept patch (no tests so far, and probably is there a better way to check the mimetype).

[Facundo Batista]

Proof of concept patch showing what the fix would probably be

[Tim Graham]

I think we couldn't make this change as proposed because it could be backwards incompatible (data could now be a different type in request.POST, correct?).

I think we can mark this as a duplicate of #21442.

[timtaiwanliim]

These 3 issues are related.
[1] https://code.djangoproject.com/ticket/21442
[2] https://code.djangoproject.com/ticket/28678
[3] ​https://github.com/encode/django-rest-framework/issues/4881

[1] is the overall tracker for this issue, desires to create a configurable parser. Opened 9 years ago.
[3] describes the desired behavior with example. Opened 5 years ago.
[2] has a proposed fix (credit: Facundo Batista). The fix is simple and worked well when I tried it. Opened 5 years ago.

Surely a configurable parser [1] is a good goal to pursue. But if it
takes 9 years before anything happens, perhaps we can take [2]? It is
not configurable, but it works well.

re: a case for multipart parser that can handle json parts
I have an api that takes some json input, plus 2 optional image files.
With json parser, I cannot easily include image files (base64 works, but
clumsy for modest size images).
Multipart parser allows me to send the json input plus images in 1
call. But all the data parts are treated as text (str). One of the
data field is a dict (eg. { "x": 7, "y": 5 }).
If I use json parser, it is an dict (good).
If I use multipart parser, it becomes a str (bad; desired to get a
dict).

it could be backwards incompatible (data could now be a different type in request.POST, correct?).

Not so.
Only if the parts have http header "content-type: application/json",
then those parts become dict (the desired type; currently of str
type).
For the parts (of multiparts) that do not have "content-type" header,
the results remain as str type.
(see [3] for an example of the "content-type" of the parts)

[Claude Paroz]

Replying to timtaiwanliim:

it could be backwards incompatible (data could now be a different type in request.POST, correct?).

Not so.
Only if the parts have http header "content-type: application/json",
then those parts become dict (the desired type; currently of str
type).
For the parts (of multiparts) that do not have "content-type" header,
the results remain as str type.

That's indeed the backwards compatibility issue: typically, current code expects a str and call json.loads(data) to convert it to a Python structure. If suddenly the data is another Python structure (dict, list, etc.), the same code will suddenly crash with an error like TypeError: the JSON object must be str, bytes or bytearray, not dict. Do you have an idea to avoid that issue?