Opened 11 years ago

Last modified 4 weeks ago

#21442 assigned New feature

Configurable request parsing.

Reported by: Tom Christie Owned by: Carlton Gibson
Component: HTTP handling Version: dev
Severity: Normal Keywords:
Cc: antonis+djangoproject.com@…, Mark Lavin, Abhinav Yadav, Charles Roelli Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

This ticket if for implementing a request parsing API that ensures the Request objects can nicely handle JSON and other submitted types in addition the the existing multipart parsing.

The proposed API is based on this discussion: https://groups.google.com/forum/#!searchin/django-developers/request.DATA/django-developers/s8OZ9yNh-8c/oCbNL5x6avAJ

  • request.DATA or request.data for accessing the parsed data.
  • request.parsers or similar for modifying the parsers prior to parsing on a per-view basis.
  • request.accepted_parser or similar for branching on media type if needed.
  • A setting REQUEST_PARSERS or similar, that controls the default set of installed parsers.

Change History (16)

comment:1 by Tim Graham, 11 years ago

Triage Stage: UnreviewedAccepted

comment:2 by akanouras, 11 years ago

Cc: antonis+djangoproject.com@… added

comment:3 by Tom Christie, 10 years ago

Owner: changed from nobody to Tom Christie
Status: newassigned

comment:4 by Asif Saifuddin Auvi, 9 years ago

https://github.com/django/deps/blob/master/draft/content-negotiation.rst

reading the DEP

my thoughts are wouldn't it better/nicer to handle the content negotiation per view based content negotiation? and there should be decorators to handle content negotiation in view level?

+ is it really necessary to introduce new global settings?

comment:5 by Asif Saifuddin Auvi, 9 years ago

or this is the HTTP Handling part only? view parts will be implemented differently in another ticket? serialization in another part? hope you don't get me wrong for asking too many questions.

comment:6 by Mark Lavin, 7 years ago

Cc: Mark Lavin added

comment:7 by DoHyun Kim, 6 years ago

How's it going? Any update about this issue?

comment:8 by Mariusz Felisiak, 3 years ago

Owner: Tom Christie removed
Status: assignednew

comment:9 by timtaiwanliim, 2 years ago

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).

comment:10 by Carlton Gibson, 2 years ago

Owner: set to Carlton Gibson
Patch needs improvement: set
Status: newassigned

Following thread on mailing list, we're going to approach by adding the request.data part, adding just JSON handling, before making the accepted content types pluggable as a second step.

Beginning work over here. Not yet ready.

Related to #32259 to modernise the request object at the same time.

comment:11 by Carlton Gibson, 18 months ago

Owner: Carlton Gibson removed
Status: assignednew

De-assigning myself as this has been picked up for GSoC this year.

comment:12 by Abhinav Yadav, 18 months ago

Owner: set to Abhinav Yadav
Status: newassigned

comment:13 by Carlton Gibson, 13 months ago

Owner: changed from Abhinav Yadav to Carlton Gibson

OK, this didn’t make it in GSoC. I’m going to pick this back up.

comment:14 by Mariusz Felisiak <felisiak.mariusz@…>, 11 months ago

In 76280b4f:

Refs #21442 -- Increased test coverage of requests.

comment:15 by Abhinav Yadav, 11 months ago

Cc: Abhinav Yadav added

comment:16 by Charles Roelli, 4 weeks ago

Cc: Charles Roelli added
Note: See TracTickets for help on using tickets.
Back to Top