[Django] #36245: Implement Configurable Content Type Parsing `request.data` to Modernize the HTTPRequest

[Django]

#36245: Implement Configurable Content Type Parsing `request.data` to Modernize the
HTTPRequest
-----------------------------------------+-------------------------------
Reporter: Adya | Owner: Adya
Type: New feature | Status: assigned
Component: HTTP handling | Version: 5.1
Severity: Normal | Keywords: parsing, http
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+-------------------------------
Adding a new feature to modernize the `HTTPRequest` object, adding a
content-type aware `request.data` property. This will parse `request.body`
according to the content type.

In the initial phase, I will add `request.data` and add support for JSON
body handling, but the next phase is to make that fully pluggable with
custom parsers.

This Feature Idea is described in the Django GSoC 2025 Wiki page
https://code.djangoproject.com/wiki/SummerOfCode2025#ConfigurableContentTypeParsing

This kind of feature is already implemented in *Django REST Framework* I
have read the source code, DRF, Django docs, MDN reference on HTTP, and
implemented it in my local Django project.
A [PlanEnglish.io Python blog](https://python.plainenglish.io/django-rest-
api-tutorial-mastering-parsers-with-practical-examples-d24872c47849)
described it so well.

**Outcome after completing this feature**
Developers will have a more streamlined and efficient way to access
request data
For instance, with `request.body`, a developer working with JSON data
would need to write

```python
import json
data = json.loads(request.body)
user_name = data.get('name')
```

With the proposed `request.data`, this simplifies to something like:
```
user_name = request.data.get('name')
```
I am creating the test cases and patches for this implementation then PR
it
**Implementation Plan:**
- Write test cases
- Add the request.data property to HTTPRequest.
- Implement initial JSON parsing logic.
--
Ticket URL: <https://code.djangoproject.com/ticket/36245>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#36245: Implement Configurable Content Type Parsing `request.data` to Modernize the
HTTPRequest

-------------------------------+--------------------------------------

Reporter: Adya | Owner: Adya
Type: New feature | Status: assigned
Component: HTTP handling | Version: 5.1

Severity: Normal | Resolution:

Keywords: parsing, http | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0

-------------------------------+--------------------------------------
Description changed by Adya:

Old description:

New description:

Adding a new feature to modernize the `HTTPRequest` object, adding a
content-type aware `request.data` property. This will parse `request.body`
according to the content type.

In the initial phase, I will add `request.data` and add support for JSON
body handling, but the next phase is to make that fully pluggable with
custom parsers.

This Feature Idea is described in the Django GSoC 2025 Wiki page
https://code.djangoproject.com/wiki/SummerOfCode2025#ConfigurableContentTypeParsing

This kind of feature is already implemented in *Django REST Framework* I
have read the source code, DRF, Django docs, MDN reference on HTTP, and
implemented it in my local Django project.
A [PlanEnglish.io Python blog](https://python.plainenglish.io/django-rest-
api-tutorial-mastering-parsers-with-practical-examples-d24872c47849)
described it so well.

**Outcome after completing this feature**
Developers will have a more streamlined and efficient way to access
request data
For instance, with `request.body`, a developer working with JSON data
would need to write

```python
import json
data = json.loads(request.body)
user_name = data.get('name')
```

With the proposed `request.data`, this simplifies to something like:

```python

user_name = request.data.get('name')
```
I am creating the test cases and patches for this implementation then PR
it
**Implementation Plan:**
- Write test cases
- Add the request.data property to HTTPRequest.
- Implement initial JSON parsing logic.

--

--
Ticket URL: <https://code.djangoproject.com/ticket/36245#comment:1>

[Django]

> ```python
> user_name = request.data.get('name')
> ```
> I am creating the test cases and patches for this implementation then PR
> it
> **Implementation Plan:**
> - Write test cases
> - Add the request.data property to HTTPRequest.
> - Implement initial JSON parsing logic.

--
--
Ticket URL: <https://code.djangoproject.com/ticket/36245#comment:2>

[Django]

I am creating the test cases and patches for this implementation, then
will PR it

**Implementation Plan:**
- Write test cases
- Add the request.data property to HTTPRequest.
- Implement initial JSON parsing logic.

--
--

Ticket URL: <https://code.djangoproject.com/ticket/36245#comment:3>

[Django]

_**I AM ASKING FOR TRIAGE**_

--
--
Ticket URL: <https://code.djangoproject.com/ticket/36245#comment:4>

[Django]

#36245: Implement Configurable Content Type Parsing `request.data` to Modernize the
HTTPRequest
-------------------------------+--------------------------------------
Reporter: Adya | Owner: Adya

Type: New feature | Status: closed

Component: HTTP handling | Version: 5.1

Severity: Normal | Resolution: duplicate

Keywords: parsing, http | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------

Changes (by Sarah Boyce):

* resolution: => duplicate
* status: assigned => closed

Comment:

Thank you! I think this is a duplicate of #21442
--
Ticket URL: <https://code.djangoproject.com/ticket/36245#comment:5>

[Django]

#36245: Implement Configurable Content Type Parsing `request.data` to Modernize the
HTTPRequest
-------------------------------+--------------------------------------
Reporter: Adya | Owner: Adya
Type: New feature | Status: closed
Component: HTTP handling | Version: 5.1
Severity: Normal | Resolution: duplicate
Keywords: parsing, http | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------

Comment (by Adya):

Replying to [comment:5 Sarah Boyce]:
> Thank you very much for the comment, I had already checked this ticket,
maybe there was a confusion .
I think PR and discussion in ticket
https://code.djangoproject.com/ticket/21442, It is not active after some
progress for the last 5 months. And according to Django GSoC Idea page it
is mentioned that contributors have to accomplish it in **two phases**. So
I opened a ticket for the initial phase. It is mentioned here
https://code.djangoproject.com/wiki/SummerOfCode2025#ConfigurableContentTypeParsing

But this idea is proposed in Django **GSoC 2025** and I am working on it,
on the current Django Development version.

*I am discussing in the Forum too
https://forum.djangoproject.com/u/adyaprasad/summary*

**For the Initial phase I have implemented changes in
`django/http/request.py` and `django/http/response.py`**
In `django/http/request.py` something like (reference short code)
{{{
class HttpRequest:
# ... existing code ...

@property
def data(self):
"""
Parses and returns the request body based on Content-Type.

Currently supports:
* 'application/json': Returns the parsed JSON data
* All other content types: Returns an empty dictionary
"""
if not hasattr(self, '_cached_data'):
content_type = self.headers.get('Content-Type', '')
# Extract the main content type without parameters
content_type = content_type.split(';')[0].strip()

if content_type == 'application/json':
if not self.body:
self._cached_data = {}
else:
try:
self._cached_data =
json.loads(self.body.decode('utf-8'))
except (ValueError, UnicodeDecodeError) as exc:
from django.core.exceptions import BadRequest
raise BadRequest(f"JSON parse error - {str(exc)}")
else:
# For the initial phase, return empty dict for non-JSON
content
self._cached_data = {}

return self._cached_data

}}}
I can change the code if need and not fit
My proposal and research paper are almost ready, I am working on the Test
Cases

**Please help me, what should I do now? Either assigned me ticket #21442
and opened and assigned me this ticket**
**What would you like to recommend?**
🤞
--
Ticket URL: <https://code.djangoproject.com/ticket/36245#comment:6>

[Django]

#36245: Implement Configurable Content Type Parsing `request.data` to Modernize the
HTTPRequest
-------------------------------+--------------------------------------
Reporter: Adya | Owner: Adya

Type: New feature | Status: new

Component: HTTP handling | Version: 5.1
Severity: Normal | Resolution:

Keywords: parsing, http | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------

Changes (by Adya):

* resolution: duplicate =>
* status: closed => new

--
Ticket URL: <https://code.djangoproject.com/ticket/36245#comment:7>

[Django]

#36245: Implement Configurable Content Type Parsing `request.data` to Modernize the
HTTPRequest
-------------------------------+--------------------------------------
Reporter: Adya | Owner: Adya

Type: New feature | Status: closed

Component: HTTP handling | Version: dev
Severity: Normal | Resolution: duplicate

Keywords: parsing, http | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------

Changes (by Natalia Bidart):

* resolution: => duplicate
* status: new => closed
* version: 5.1 => dev

Comment:

Hello Adya,

This Django ticket tracker is for confirmed bugs and accepted feature
work, not for GSoC project tracking or mentorship. Ticket #21442 is the
official ticket for this feature, and it is already assigned and has some
work in progress. Any work on it should be coordinated through the Django
Forum or the GSoC platform, not by opening new tickets in Trac.

If you need guidance on your proposal, please continue discussions in the
[https://forum.djangoproject.com Django Forum] and eventually submit your
proposal through GSoC's official platform. Trac is not the place for
proposal reviews, test case discussions, or mentorship.

Thank you!
--
Ticket URL: <https://code.djangoproject.com/ticket/36245#comment:8>

[Django]

#36245: Implement Configurable Content Type Parsing `request.data` to Modernize the
HTTPRequest
-------------------------------+--------------------------------------
Reporter: Adya | Owner: Adya
Type: New feature | Status: closed
Component: HTTP handling | Version: dev
Severity: Normal | Resolution: duplicate
Keywords: parsing, http | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------

Comment (by Adya):

Hey Natalia😊, Thanks for this confirmation.
I get confused because this ticket is not mentioned in the content Idea
description.
https://code.djangoproject.com/wiki/SummerOfCode2025#ConfigurableContentTypeParsing.

But in the description a statement is given:
>The initial phase — targeted for before GSoC — will add request.data and

add support for JSON body handling, but the next phase is to make that
fully pluggable with custom parsers.

What about the initial stage requirements, should I leave it? Will this
problem occur if I did not complete an initial phase statement myself? Or
it would be okay to leave OR #21442 ticket will get counted as initial
phase completion.

Just tell me what I should do now?
--
Ticket URL: <https://code.djangoproject.com/ticket/36245#comment:9>

[Django]

#36245: Implement Configurable Content Type Parsing `request.data` to Modernize the
HTTPRequest
-------------------------------+--------------------------------------
Reporter: Adya | Owner: Adya
Type: New feature | Status: closed
Component: HTTP handling | Version: dev
Severity: Normal | Resolution: duplicate
Keywords: parsing, http | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------

Comment (by Natalia Bidart):

Replying to [comment:9 Adya]:

> Hey Natalia😊, Thanks for this confirmation.
> I get confused because this ticket is not mentioned in the content Idea
description.
https://code.djangoproject.com/wiki/SummerOfCode2025#ConfigurableContentTypeParsing.

Yes, sorry about that, there was a misunderstanding and despite this topic
was listed in the wiki page, it's not really available for GSoC. Some
extra data:

* the feature already has people working on it (the ones assigned in the
main ticket)
* a few conversations have already occurred in the forum and there was a
request to write a DEP for this first (see
https://forum.djangoproject.com/t/request-for-steering-council-vote-on-
modernising-the-request-object/26816)
* the DEP is still in progress at https://github.com/django/deps/pull/88

So at this point there is no much to do on this topic except to
potentially contribute to the DEP to get that finalized and approved.
--
Ticket URL: <https://code.djangoproject.com/ticket/36245#comment:10>

[Django]

#36245: Implement Configurable Content Type Parsing `request.data` to Modernize the
HTTPRequest
-------------------------------+--------------------------------------
Reporter: Adya | Owner: Adya
Type: New feature | Status: closed
Component: HTTP handling | Version: dev
Severity: Normal | Resolution: duplicate
Keywords: parsing, http | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------

Comment (by Adya):

Replying to [comment:10 Natalia Bidart]:

> Yes, sorry about that, there was a misunderstanding and despite this
topic was listed in the wiki page, it's not really available for GSoC.
Some extra data:
>
> * the feature already has people working on it (the ones assigned in the
main ticket)
> * a few conversations have already occurred in the forum and there was a
request to write a DEP for this first (see
https://forum.djangoproject.com/t/request-for-steering-council-vote-on-
modernising-the-request-object/26816)
> * the DEP is still in progress at https://github.com/django/deps/pull/88
>
> So at this point there is no much to do on this topic except to
potentially contribute to the DEP to get that finalized and approved.

Thanks again for this direction, Natalia. There are 5 ideas listed the
wiki page currently, could you recommend any idea or ticket to work
(ticket: triage ticket and unassigned).
Main concern is that the idea or ticket on which I could get a potential
mentor. In the forum, mentor unavailability is a major concern. So I need
to choose a idea for which I could get a mentor
--
Ticket URL: <https://code.djangoproject.com/ticket/36245#comment:11>