Support for multipart/form-data to allow uploading files about fullmoon

[pkulchenko]

@johnmuhl, this is currently not supported, but this is something I plan on adding shortly. In the meantime you should be able to use https://github.com/Kong/lua-multipart, but keep in mind that I plan to provide a more transparent API with the current params implementation, so that it's integrated with the rest of the checks and logic in the library. It's likely though that GetBody will still return the submitted MIME message, so using other libraries will still work. I'll keep the ticket open and update it when the new implementation is available.

Thanks for the pointer to lua-multipart. That works for now. Will keep an eye out for the fm implementation.

[pkulchenko]

@johnmuhl, how do you expect to access the headers (or any additional details like the filename)? It's convenient to return just one value (so r.params.myfieldname returns the fileitself), but then the name and other header values are not easily available. I'm thinking about returning a table, which would then allow .value field to access its value and .filename field to access the filename (in addition to the rest of the headers).

I'm really new to lua so I'm not sure what is idiomatic or the obvious thing yet but a table sounds good to me. Using the multipart library I ran into exactly the problem you describe with returning just one value. I ended up with something like:

local mp = multipart(r.body, content_type)
local images = mp:get_as_array("images")
for i, _i in pairs(mp._data.indexes["images"]) do
    -- _data is some internal structure
    local ct, ex = mp._data.data[_i].headers[2]:match("^Content%-Type%:%s(.-)%/(.-)$")
    -- image is the raw file content
    local image = images[i]
end

There is probably a better way but I got the idea from their tests after struggling to figure it out.

In rack (for ruby) you get an array of hashes with { type, filename, tempfile } (and a couple of others) and it works out nicely. You do have to name the input like <input name="images[]"...> for multiple so it knows to handle those params differently (without the [] you just get a hash of type, etc). I think my first thought was to try something like:

for k, v in pairs(r.params.images) do
    -- poke around hoping to find
    -- v.headers, v.data, etc.
end

[pkulchenko]

for k, v in pairs(r.params.images) do
    -- poke around hoping to find
    -- v.headers, v.data, etc.
end

Yes, that's exactly how it's working today, but I think there is still some advantage in returning the exact value, as it would allow using multipart parameters in route filters. So, I'm still debating whether r.params.myname would return the value itself and r.params.multipart.myname would return a table with all the details (including filename and the headers). If I can't get this to work for some reason, I'll keep the current implementation.

I also added support for params.images in addition to params["images[]"] based on your suggestion.

[pkulchenko]

@johnmuhl, pushed the changes along with the documentation. It should work exactly as you listed (and the parameter filtering should work as well). Can you give it a try and let me know if something needs to be adjusted or added to the documentation?

Works great. I had to change:

https://github.com/pkulchenko/fullmoon/blob/master/fullmoon.lua#L1287

to return m and m.data or m to avoid an "attempt to index nil value" error but haven't tracked down why I need that yet.

[pkulchenko]

I think you're right; it may be a bug. I suspect it's supposed to be if m then return m.data or m end, as it should still allow the fall-through to other keys (not present in the multipart messages). I'll confirm with tests and push a fix later today.

[pkulchenko]

to return m and m.data or m to avoid an "attempt to index nil value" error but haven't tracked down why I need that yet.

@johnmuhl, this should be fixed now. Can you confirm when you get a chance? Thanks!

Yep that fixed it. Thanks again.