This is an attempt to address the current shortcomings of big file upload as already discussed in #229.
The idea is to avoid storing possibly huge file upload in memory, at least not by default. The post processor mechanism from libmicrohttpd is used for parsing mime-types multipart/form-data and application/x-www-form-urlencoded (don't reinvent the wheel!) and text based key/value pairs are put to args as usual.
Parts with a filename should be written to some C++ stream, a file stream would fit my needs and is shown here as proof of concept. Maybe we want to generalize that somehow? Later?
Initial version of this PR is a draft as base for discussion.
Alternate Designs
Open for suggestions.
Possible Drawbacks
It is not possible to get the whole multipart/form-data through http_request::get_content() anymore.
Verification Process
Works on the bench with an example app not shown here. Should be improved of course.
LeSpocky
commented
2 years ago
Identify the Bug
229
Description of the Change
This is an attempt to address the current shortcomings of big file upload as already discussed in #229.
The idea is to avoid storing possibly huge file upload in memory, at least not by default. The post processor mechanism from libmicrohttpd is used for parsing mime-types multipart/form-data and application/x-www-form-urlencoded (don't reinvent the wheel!) and text based key/value pairs are put to args as usual.
Parts with a filename should be written to some C++ stream, a file stream would fit my needs and is shown here as proof of concept. Maybe we want to generalize that somehow? Later?
Initial version of this PR is a draft as base for discussion.
Alternate Designs
Open for suggestions.
Possible Drawbacks
It is not possible to get the whole multipart/form-data through
http_request::get_content()anymore.Verification Process
Works on the bench with an example app not shown here. Should be improved of course.
Release Notes
tbd