# Request for Steering Council vote on modernising the request object. **URL:** \ **Category:** Django Internals\ **Created:** [January 10, 2024, 3:37pm UTC](https://forum.djangoproject.com/t/request-for-steering-council-vote-on-modernising-the-request-object/26816 "2024-01-10T15:37:09Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![carltongibson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/carltongibson/32/267_2.png) [@carltongibson](https://forum.djangoproject.com/u/carltongibson)\ **Post date:** [January 10, 2024, 3:37pm UTC](https://forum.djangoproject.com/t/request-for-steering-council-vote-on-modernising-the-request-object/26816/1 "2024-01-10T15:37:09Z")
Hi. Happy New Year. I need to ask for a Steering Council ([@steering\_council](https://forum.djangoproject.com/groups/steering_council)) approval (vote under rules of DEP 10) for a proposal to modernise the API of the `HttpRequest` object, whilst adding content type aware parsing, such that (in particular) JSON request bodies can be handled automatically. The body of the proposal is that new attributes are added to the request, which are roughly equivalent to the existing `GET` &co, but which have more modern names: - `query_params` (for `GET`) - `data` (for `POST`, but see note) - `files` (for `FILES`) - `meta` (for `META`) The new `data` attribute is not 100% equivalent to `POST` since it will parse JSON (and other data types as parsers for those are configured) where `POST` would return a string. (The behaviour for multipart requests will also be slightly different as per the django-developers thread linked below.) The existing `GET`, `POST`, `META`, and `FILES` attributes will be maintained for backwards compatibility, and (to emphasise again) the behaviour (specifically of `POST`) will remain unchanged. This is similar to the way the `headers` property was added, whilst maintaining the older dictionary style lookup. Modernising the request, whilst attractive in itself, gives us the opportunity to resolve the long-standing content negotiation issue, which has been blocked several times for backwards compatibility concerns. There are two open PRs relevant to this: - [Refs #21442 – Modernising Request Object Attribute Names. By SirAbhi13 · Pull Request #17624 · Django/Django](https://github.com/django/django/pull/17624) - [Refs #21442 – Added Content Type Parsing by smithdc1 · Pull Request #17546 · Django/Django](https://github.com/django/django/pull/17546) The request is to be able to push these forwards, subject to the usual reviews and quality requirements. (They’re not yet finished.) To recall the history here: - We were about to merge the fix for [ticket-32259](https://code.djangoproject.com/ticket/32259), before @felixxm thought under review that it was too disruptive. He and I (as the current fellows at that time) discussed and agreed on this. - @adamchainz asked for [technical board review](https://forum.djangoproject.com/t/technical-board-vote-on-ticket-32259-modernize-request-attribute-names/10255) wherein it was agreed that allowing the suggestion of _buying some functionality_ with the content negotiation work should be explored. - I followed up with a thread to [Advance the content negotiation proposal](https://groups.google.com/g/django-developers/c/O8WfDpplXuI/m/Aj3iIFu8AwAJ) attempting to fulfil that promise, where it was agreed that we would proceed on this basis. Mariusz has raised the same concerns again now, and we would like the Steering Council to decide the way forward. Please vote on whether to approve advancing the two PRs. (Taking +1 to be for doing so, -1 to be against, to align with the DEP 10 voting procedure.) If the decision is against, can I ask the Steering Council to provide guidance as to how we might or should then move forward with efforts to modernise the request. Thanks! 🎁 Carlton ---
**Author:** ![andrewgodwin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/andrewgodwin/32/2_2.png) [@andrewgodwin](https://forum.djangoproject.com/u/andrewgodwin)\ **Post date:** [January 10, 2024, 6:19pm UTC](https://forum.djangoproject.com/t/request-for-steering-council-vote-on-modernising-the-request-object/26816/2 "2024-01-10T18:19:01Z")
Hi Carlton - it’s a little unusual to ask for this without a full DEP, as we basically only have the intro to your post to go off of in terms of the desired specification here. DEPs are valuable to me in that they capture both the desired changes and the reasoning - is there a reason not to do one here? I don’t need it to be long, but I’d rather this reasoning was captured centrally rather than spread out over several threads and PRs. (I will even help shepherd or author the DEP if you like!) ---
**Author:** ![carltongibson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/carltongibson/32/267_2.png) [@carltongibson](https://forum.djangoproject.com/u/carltongibson)\ **Post date:** [January 10, 2024, 6:24pm UTC](https://forum.djangoproject.com/t/request-for-steering-council-vote-on-modernising-the-request-object/26816/3 "2024-01-10T18:24:59Z")
OK, no problem. I’ll get on that. (Only reason is that the history is already quite extensive, but yes, it doesn’t hurt to write it up again.) ---
**Author:** ![adamchainz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/adamchainz/32/26_2.png) [@adamchainz](https://forum.djangoproject.com/u/adamchainz)\ **Post date:** [January 11, 2024, 11:37pm UTC](https://forum.djangoproject.com/t/request-for-steering-council-vote-on-modernising-the-request-object/26816/4 "2024-01-11T23:37:57Z")
Thanks for championing this change, Carlton \<3 . A short DEP would be great, as Andrew says. > [@carltongibson](#): > > roughly equivalent Fully equivalent, no? ---
**Author:** ![apollo13](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/apollo13/32/30_2.png) [@apollo13](https://forum.djangoproject.com/u/apollo13)\ **Post date:** [January 12, 2024, 6:43am UTC](https://forum.djangoproject.com/t/request-for-steering-council-vote-on-modernising-the-request-object/26816/5 "2024-01-12T06:43:12Z")
No, not fully equivalent (see the note on POST vs data).