Request for Steering Council vote on modernising the request object.

Django Internals
1

Hi. Happy New Year.

I need to ask for a Steering Council (@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:

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, 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 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 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! :gift:

Carlton

4 Likes
2

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

3

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

4

Thanks for championing this change, Carlton <3 . A short DEP would be great, as Andrew says.

Fully equivalent, no?

5

No, not fully equivalent (see the note on POST vs data).