cc@D3X,@tomchristie.

Hi Tom, see my commenthere for context. It seems like settingrequest._post in addition torequest._files might have been the correct thing to do. Thoughts?

@rpkilby One thing I'm concerned about is that this changes the contract onrequest._post.

Normally, Django would set it to an emptyQueryDict if the Content-Type of the request was not "application/x-www-form-urlencoded" or "multipart/form-data".

With this PR, it gets set to parsed data even for other types, like "application/json". This could result in not-easy-to-track bugs if some middlewares depended on Django's behaviour in this case.

This shouldn't impact middlewares as they are called with Django's request. DRF's views does the wrapping so it's really used "inside" DRF whether core or the application code.

@xordoquy I wrote a short test to show how the interface on request.POST changes when using DRF and posting JSON:D3X@aa6a4c4

I don't know any app that would break because of it, but it is possible some would.

@D3X - thanks, good catch.

@rpkilby This looks fine to me — I'm inclined to just pull it in, but I'm not quite seeing how the commits match the conversation. (Did you rebase? What changed?)

I wrote a short test to show how the interface on request.POST changes...

OK, added, but what wasthis line in the first version?

     self._request._post = self.POST

Thanks!

@carltongibson - yeah, I amended the commits from earlier in the conversation. Previously was

self._request._post=self._dataself._request._files=self._files

@rpkilby OK, thanks. That makes perfect sense.

I have no idea how this PR works.
_load_data_and_files callPOST which may call_load_data_and_files.

@xordoquy - it's definitely weird, but it won't reenter. eg, if you callrequest.POST, it will trigger the call to_load_data_and_files(). At this point,_data/_files/_full_data are set, so the inner call torequest.POST won't call_load_data_and_files() again.