SimpleRequest.body doesn't return the full body when the body has binary data about zap HOT 8 CLOSED

To explain the debug output. The Content-Length is 2661 bytes but SimpleRequest.body.len shows only 157 bytes.
This problem won't show up if the embedded file is text. I have a feeling there is some kind of C -> Zig error.

from zap.

I can verify that facil.io indeed has the full body in the request. The binary data is causing zero-delimited sentinel to fail. I now use body.ptr[0..length] instead of Simple.Request.body to properly parse body for multipart form. Of course I'm duplicating the work facil.io already does fio.http_parse_body(self.h) but I don't know how to retrieve the result of SimpleRequest.parseBody() for multipart form. Not sure how to get it from parameters because the value of the parameter is shown to be null when I use SimpleRequest.parseBody() and then getParametersToOwnedSlices().

The current code in Zap is assigning .body = util.fio2str(r.*.body), I believe the proper way is to get the length from "content-length" and then calling r.*.body[0..length] because there could be null (zero) in the body.

from zap.

You're right. The current implementation using fio2str assuming text-data. Mime-encoded 'binary' data would be handled by that. But real binary data cannot. This is a flaw and requires a bit of thought to get it fixed. We may be lucky and your proposed fix will work without side-effects. Then, at least you should be able to use the SimpleRequest.body. Using the length from 'content-length' may be problematic as it would open zap up to potential segfault / panic attacks by pretending to send n bytes in content-length but actually sending less bytes -> zap tries to access random memory. So, the body length must be somewhere in facilio - we should use that IMHO

from zap.

OK, I fixed the SimpleRequest.body (in the bindata branch FYI). Alas, when trying to access the binary parameter, facilio seems to treat the value as a hashmap which is not supported by zap. I'm investigating...

[EDIT]: OK, seems non-trivial. When I receive a binary file via curl in a multipart form, facilio creates a hashmap containing filename, mimetype, and data. The data itself seems to "must be" read() from, apparently. I'll try to wrap this so all you get are u8 slices.

from zap.

Dammit. When I try to read from the data, it doesn't work, and pretends to be 0 bytes long. Check out the bindata branch if you like to check what I might have f-ed up.

from zap.

@renerocksai thanks for keeping at it. I'll take a look. I agree with not being able to trust "Content-Length" for attacks but there really is no other way unless facil.io can count the number of bytes coming in the pipe directly.
I see a big portion of the code in facil.io parsing the form-data but I just did my own parsing.
One stop gap solution would be checking the content-type and only do the body parsing and "trusting" content-length if we get the special binary form-data content-type.
The problem is what does the server do by default if it receives the data? One way is to register a callback so that the callback is called for each binary file parsed and the callback can do whatever (like saving the file which is what I do right now.

from zap.

See https://github.com/zigzap/zap/blob/master/examples/bindataformpost/bindataformpost.zig

There, I iterate over the parametersToOwnedList and check the tag of the params. If it's a binary file, I print it. You could add all other types or an else branch there according to your needs. It might be a bigger pain in the a.. having to check them all but in the else branch you know it's not a file so you could getParamStr(paramname) and retrieve the string version as usual

from zap.

in fact, I just updated the example to showcase this usecase

from zap.