HTTP POST Dictionary should not be populated unconditionally

[eric@…]

When Django creates an HttpRequest object, it appears to populate the POST property by creating a QueryDict using the contents of the POST entity body unless the Content-Type header begins with "multipart" (in which case it attempts to process a file upload). This behavior produces a garbage POST dictionary if the contents of the entity body are arbitrary binary data. The populating of the POST QueryDict should be skipped unless the Content-Type specifies such processing (such as for URL-encoded form data). It should not perform this processing, for example, if the Content-Type is application/octet-stream.

[Aymeric Augustin]

It appears to me that request.POST is loaded lazily at the first access.

Could you clarify why you think it's unconditionally loaded at the creation of the HttpRequest?

[anonymous]

Yes, what I meant to say that although it is lazily loaded, if accessed, it is unconditionally populated with the contents of the entity body. The resulting QueryDict is garbage. An application that attempts to access request.POST (or request.REQUEST) may get erroneous results. The specific case I ran into is that in the application/octet-stream entity body, there were values that could get parsed into name/value pairs in request._post. However, they were never intended as query or form data parameters, yet showed up in the request.POST dictionary. The application attempted to locate a parameter which was NOT specified in the query parameters, but which showed up in request.POST because it was put there upon lazy loading of the post data.

[Claude Paroz]

I think this is a valid concern and a duplicate of #5611. We currently assume that POST content is either multipart or form-urlencoded. We are not prepared to handle a POST request like:

POST /url HTTP/1.1
Host: www.example.com
User-Agent: ...
Content-Type: application/octet-stream
Content-Length: n

Here is binary content