Do not remove empty GET/POST parameters #585

wants to merge 2 commits into


None yet

5 participants


Is there a reason why tornado currently removes empty GET/POST parameters? It is causing issues with validating forms generated by formalchemy, because formalchemy expects GET/POST parameters to be there, even if they are empty.


This pull request passes (merged ebf17aa into 2b07385).


Especially useful for OAuth basestring calculation, when you need list of all parameters even if they have empty values.


This has come up several times before and I think it's a good change (with the exception that I'm not sure whether the singular RequestHandler.get_argument should treat empty arguments as unspecified). It is potentially backwards-compatibile, though, so I'd like to hold off until tornado 3.0 (which is not that far off - I'm going to do a 2.4 release soon and then next will probably be 3.0).

@bdarnell bdarnell added a commit that closed this pull request Sep 10, 2012
@bdarnell bdarnell Merge commit 'ebf17aa'
Closes #585.
@bdarnell bdarnell closed this in f1ae398 Sep 10, 2012

FYI, this pull does not enable empty POST parameters. I've submitted a pull here with the update: #614


@kung-foo nice catch, but still incomplete :P your pull does not enable empty POST parameters for requests with Content-Type multipart/form-data


ah yes. now I remember starting to look into the multipart processing code and thinking, wtf. nope. 😐


@kung-foo false alarm 😊 your patch seems to be fine. I've checked again parse_multipart_form_data implementation and figured out that there is no filter for empty values on multipart data forms. maybe need to add tests for this case.

@Rudd-O Rudd-O pushed a commit to Rudd-O/tornado that referenced this pull request Jun 27, 2013
@bdarnell bdarnell Merge commit 'ebf17aa'
Closes #585.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment