Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#2183 closed enhancement (fixed)

Empty posts are still posts

Reported by: jdunck@… Owned by: adrian
Component: Generic views Version: 0.90
Severity: minor Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


When posting a form with no successful controls, request.POST evaluates to false in a boolean context. This causes the POST action to not be handled.

It'd be nice to still handle the post requests.

(Work around is to have a dummy form input or to name the submit button in the HTML.)

Change History (7)

comment:1 Changed 9 years ago by mtredinnick

The two options that I see for fixing this are to (1) make the MultiValueDict return True whenever the request type is POST, or (2) improve the documentation to say that if you are posting a form with no data in it, you also need to check request.METAREQUEST_TYPE? in your view function. Testing request.POST for "truth" is only an idiom, not compulsory.

I'm not sure I have a strong opinion one way or the other here. Listing the options for now for the benefit of future explorers.

comment:2 Changed 9 years ago by ubernostrum

A couple of concerns to take into consideration: (link goes to post on django-users)

comment:3 Changed 9 years ago by anonymous

From: James Bennett <ubernostrum@…>
Date: Jun 17, 2006 8:25 PM
Subject: Re: POST to view loses POST data
To: django-users@…

On 6/17/06, Malcolm Tredinnick <malcolm@…> wrote:

There is already a way to test for posts via the request object:
request.METAREQUEST_METHOD?. But your suggestion is not unreasonable,
so best to file a ticket so that it can be considered without being

I'm not convinced that it'd be a good thing to have request.POST
evaluate to True in these cases, but the reasoning is somewhat

First and foremost, there's a logical difference between the request
method and the request parameters, so it makes sense that a test for
the method could evaluate to True while a test for the parameters
could evaluate to False.

Second, since request.POST is supposed to be a "dictionary-like"
object, this would be unintuitive and, dare I say, "magical" behavior
-- an empty dictionary is False.

And, of course, there are practical considerations; if I want a view
to return particular output when someone POSTs with no content, now
instead of the expected "if not request.POST" -- checking for an empty
dictionary -- I have to come up with other tests like looking at the
length of request.POST to see if it's "empty but True". Again this is

comment:4 Changed 9 years ago by adrian

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in [3164] with the introduction of request.method.

comment:5 Changed 9 years ago by adrian

I debated making request.method a magic object that would let you check via attribute access, as some syntactic sugar:

if request.method.POST:

...but I decided that would be too magic, and it would actually get in the way of people doing stuff like:

if request.method in ('GET', 'POST')

A plain string will do.

comment:6 Changed 9 years ago by anonymous

  • Component changed from Core framework to Generic views
  • milestone set to Version 0.93
  • priority changed from low to lowest
  • Severity changed from normal to minor
  • Type changed from defect to enhancement
  • Version set to 0.9

comment:7 Changed 9 years ago by adrian

  • milestone Version 0.93 deleted

Milestone Version 0.93 deleted

Note: See TracTickets for help on using tickets.
Back to Top