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

[Adya]

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

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 will PR it

Implementation Plan:

• Write test cases
• Add the request.data property to HTTPRequest.
• Implement initial JSON parsing logic.

_I AM ASKING FOR TRIAGE_

[Sarah Boyce]

Thank you! I think this is a duplicate of #21442

[Adya]

Replying to 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?
🤞

[Natalia Bidart]

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 ​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!

[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?

[Natalia Bidart]

Replying to 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.

[Adya]

Replying to 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