<div dir="ltr"><br><br><div class="gmail_quote">On Sun, May 23, 2010 at 1:36 AM, Gregory Collins <span dir="ltr"><<a href="mailto:greg@gregorycollins.net">greg@gregorycollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>> writes:<br></div><div class="im">
<br>
> If the POST body has content-type "application/x-www-form-urlencoded" we<br>
> parse it for you and put the fields in the parameter mapping. If this<br>
> isn't your case I'd appreciate a bug report. This is a place where we<br>
> made a different design decision than you did -- a WAI application which<br>
> expects to parse the POST body itself won't work. I'll think about<br>
> adding a knob to make this behaviour optional.<br>
><br>
> I'd appreciate such a knob. Out of curiosity, do you also parse<br>
> multi-part data? <br>
<br>
</div>No, not yet :(, and we'll never do so automatically; we limit POST<br>
bodies to 1MB or something like that (to prevent malicious requests from<br>
trashing the server) but multipart requests can contain file uploads,<br>
which we would probably want to be able to stream to disk somehow.<br>
<br></blockquote><div>If you're interested, you can look at the Network.Wai.Parse module in wai-extra. The parseRequestBody function takes an argument of type Sink that specifies how data should be stored. By default, I provide an lbsSink and tempFileSink.</div>
<div><br></div><div>Michael </div></div></div>