Opened 19 months ago

Closed 19 months ago

Last modified 19 months ago

#19052 closed Bug (invalid)

HTTP POST Dictionary should not be populated unconditionally

Reported by: eric@… Owned by: nobody
Component: HTTP handling Version: 1.4
Severity: Normal Keywords: http, post
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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.

Attachments (0)

Change History (3)

comment:1 Changed 19 months ago by aaugustin

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

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?

comment:2 Changed 19 months ago by 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.

comment:3 Changed 19 months ago by claudep

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
User-Agent: ...
Content-Type: application/octet-stream
Content-Length: n

Here is binary content

Add Comment

Modify Ticket

Change Properties
<Author field>
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.