On 9/17/20 1:08 PM, wjoe wrote:
Every post or example I found copies the file, like your code does, too.
Why is that ? The content of the file upload is embedded in the form
data. There's no need for temporary files or copying at all.
On top of that, if I upload a file to a server which is on a different
PC on a different file system, how am I supposed to read the file from
disk on a remote file system ?
This makes no sense.
What I want is something like this:
~$ cat /var/log/temperatures.log
temp_1=22;temp_2=28
temp_1=21;temp_2=25
~$ curl -F "temperature_log=@/var/log/temperatures.log"
192.168.1.1:20222/temperature_upload
~$ nc -l 127.0.0.1 20222
POST /temperature_upload HTTP/1.1
Host: 192.168.1.1:20222
User-Agent: curl/7.72.0
Accept: */*
Content-Length: 245
Content-Type: multipart/form-data;
boundary=------------------------c73c71472ff9e7d5
--------------------------c73c71472ff9e7d5
Content-Disposition: form-data; name="temperature_log";
filename="/var/log/temperatures.log"
Content-Type: application/octet-stream
temp_1=22;temp_2=28
temp_1=21;temp_2=25
--------------------------c73c71472ff9e7d5--
void upload(HttpRequest.. req, blah)
{
auto file = "temperature_log" in req.files;
if (file) {
string temp_data_raw = file.data;
assert ("temp_1=22;temp_2=28\ntemp_1=21;temp_2=25" ==
temp_data_raw);
}
}
the `files` property actually does the processing only when you call it.
If you access the `bodyReader` property directly, you can process that
data yourself. You can even register a web interface function with an
`InputStream` parameter type, and it will be bound to the body data.
I've done this with my REST interface, though that's not form data.
That's not a great API, though. I would love to see vibe.d allow a
direct call to vibe.inet.webform.parseFormData with a specific handler
for files and form data.
I think you can agree that it's not feasible to store arbitrary sized
file contents in memory. But it certainly can provide a mechanism to
handle it as it's read.
-Steve
