[Django] #28678: Multipart parser should decode those JSON parts that are flagged as such
Django
-------------------------------------------+------------------------
Reporter: Facundo Batista | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.11
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 1
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------------+------------------------
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).
--
Ticket URL: <https://code.djangoproject.com/ticket/28678>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Facundo Batista | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.11
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Facundo Batista):
* Attachment "multiparser_json.diff" added.
Proof of concept patch showing what the fix would probably be
Django
Reporter: Facundo Batista | Owner: nobody
Cleanup/optimization |
Component: HTTP handling | Version: 1.11
Severity: Normal | Resolution: duplicate
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* status: new => closed
* component: Uncategorized => HTTP handling
* type: Uncategorized => Cleanup/optimization
* resolution: => duplicate
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/28678#comment:1>
Django
Reporter: Facundo Batista | Owner: nobody
Cleanup/optimization |
Component: HTTP handling | Version: 1.11
Severity: Normal | Resolution: duplicate
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by 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)
--
Ticket URL: <https://code.djangoproject.com/ticket/28678#comment:2>
Django
Reporter: Facundo Batista | Owner: nobody
Cleanup/optimization |
Component: HTTP handling | Version: 1.11
Severity: Normal | Resolution: duplicate
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Claude Paroz):
Replying to [comment:2 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?
--
Ticket URL: <https://code.djangoproject.com/ticket/28678#comment:3>