In the previous example we only looked at parameters in the
URL. Looking up values from a form submission (a POST or PUT request)
is almost the same. The only difference is we need to first decode the
request body using decodeBody:
[Source code for the app is here.]
decodeBody even needed?The body of the HTTP request is ignored unless we call
decodeBody. The obvious question is,
Why isn't the request body automatically decoded?.
If servers had unlimited RAM, disk, CPU and bandwidth available, then automatically decoding the body would be a great idea. But, since that is generally not the case, we need a way to limit or ignore form submission data that is considered excessive.
A simple solution would be to impose a static quota an all form
data submission server-wide. But, in practice, you might want finer
granularity of control. By explicitly calling decodeBody
you can easily configure a site-wide static quota. But you can also
easily adapt the quotas depending on the user, particular form, or
other criteria.
BodyPolicy and defaultBodyPolicy to impose quotasThe only argument to decodeBody is a BodyPolicy. The easiest way to define a BodyPolicy is by using the defaultBodyPolicy function:
In the example, we define this simple policy:
Since the form does not do file uploads, we set the file quota to 0. We allow 1000 bytes for the two form fields and 1000 bytes for overhead in the multipart/form-data encoding.
decodeBodyUsing decodeBody is pretty straight-forward. You simple call it with a BodyPolicy. The key things to know are:
look and friends
decodeBody only works once per request. The first time you call it the body will be decoded. The second time you call it, nothing will happen, even if you call it with a different policy.
<form>When using the <form> element there are two important recommendations you should follow:
enctype to multipart/form-data. This is especially important for forms which contain file uploads.
method to POST or the form values will show up in the URL as query parameters.