How does Tornado handle blank POST parameters?

[Chris]

Hi all,

Just tried submitting to a form as POST via jQuery with the following
parameters:

productId=bbf156e&attributeId=423e002&value=

If there's a space as "value", things work as expected. But if there's
no space, I get a warning on the Tornado side, and a 404 on the
client:

404 POST /product/setAttribute (127.0.0.1): Missing argument value

This is the bit of code that's doing it:
class ProductSetAttributeHandler(tornado.web.RequestHandler):
def post(self):
product_id = self.get_argument("productId")
attribute_id = self.get_argument("attributeId")
value = self.get_argument("value")

Is there something I can do to get value to come up as an empty string
instead of 404ing?

Thanks!

[andreas schmid]

did you try something like:

product_id = self.get_argument("productId") or ''

[selam]

value = self.get_argument("value", None)
if value:
print value

On Fri, Apr 9, 2010 at 3:11 PM, Chris <partyo...@gmail.com> wrote:
> value = self.get_argument("value")

--
Saygılar && İyi Çalışmalar
Timu EREN ( a.k.a selam )

[selam]

second parameter is default vaue

[Benjamin Golub]

http://github.com/facebook/tornado/blob/master/tornado/web.py#L182 for more details. Without the default argument Tornado will raise a 404

2010/4/9 selam <sela...@gmail.com>

--
To unsubscribe, reply using "remove me" as the subject.

[David Timothy Strauss]

I wouldn't be surprised if the HTTP spec requires omitting blank elements. You might try stripping null values prior to the construction of the POST request in jQuery.

[Chris]

I wasn't able to find a place in the HTTP spec about blank elements,
but I did dig further into Tornado and find out where the blanks are
being handled.

http://github.com/facebook/tornado/blob/master/tornado/httpserver.py#L393
arguments = cgi.parse_qs(query)

cgi.parse_qs (now urllib.parse_qs) has a parameter called
keep_blank_values, which we're not using.

http://docs.python.org/library/cgi.html#cgi.parse_qs

Would it makes sense to patch to httpserver to keep blanks?

On Apr 9, 2:11 pm, "David Timothy Strauss" <da...@fourkitchens.com>
wrote:

[Evan Long]

I experienced the same issue. Specifically a third party web service
was sending in parameters that were blank and it was still important
to know about those.

Patching might be fine but it would run the risk a breaking user code
which has a dependency on blank parameters being equivalent to non-
existent parameters when using self.get_argument.

The way I worked around the issue in my handler was to use the
underlying request object and call cgi.parse_qs myself with the
keep_blank_values set to True and that seems to work ok.

On Apr 9, 10:10 pm, Chris <partyonais...@gmail.com> wrote:
> I wasn't able to find a place in the HTTP spec about blank elements,
> but I did dig further into Tornado and find out where the blanks are
> being handled.
>

> http://github.com/facebook/tornado/blob/master/tornado/httpserver.py#...

[Chris]

Hmm...thanks for the info. Sounds like a Raymond Chen problem. :)

If blank POST parameters are allowed by the HTTP spec, then from the
principle of least surprise it would arguably make sense to have them
fall through in Tornado too. (Maybe not in this version but in a major
release...)

I think I'll use your workaround for now and let the core team decide
whether/when my patch is worthy.

[Bret Taylor]

From a practical standpoint, blank values and nonexistent values are the same thing when it comes to web forms, which motivated this behavior. get_argument("name", "") should do the trick in most cases, and this implementation helps for the 90% case when you want to treat the states the same.

Bret