On Friday, 18 September 2020 at 12:39:43 UTC, Steven
Schveighoffer wrote:
On 9/17/20 8:07 PM, wjoe wrote:
[...]
See the code here:
https://github.com/vibe-d/vibe.d/blob/ebebfa827f568cc9bced4bec2b66edc043a8adf7/inet/vibe/inet/webform.d#L311
[...]
No, not at the moment. Which is why I was saying, it could be
an enhancement request to vibe.
[...]
All the data is processed before the accessor to the form data
or the file data. It HAS to be this way, as the data is still
on the incoming network socket.
[...]
Yes
[...]
Again, enhancement request needed. The code currently is
hard-coded to write to disk.
[...]
If you had 1000 requests being processed simultaneously, and
each of those requests provided 10MB files, then you now need
potentially 10GB of RAM to hold those requests. This doesn't
scale when the application is unknown to vibe.
But again, solved with an enhancement that allows you to
process the data in your code. I'll file the enhancement
request for you, as I think it's a nice addition.
[...]
Agreed. In my case, it was an actual copy, as the location of
the stored data was on a different filesystem than the
temporary files.
[...]
Yep, it's a waste in that case.
[...]
Agreed.
[...]
In D, I'm not sure what the other frameworks do. I believe
there are others if you search on code.dlang.org, you should be
able to find some.
[...]
web development sucks in general ;) Yet, we all still do it.
-Steve
I was a little tired yesterday when I read the replies. After a
couple hours of sleep and reading them again it makes a lot more
sense to me.
Also your suggestion about a direct call to
vibe.inet.webform.parseFormData with a specific handler for files
and form data is a lot better than access via byte[].
Thanks for your help. Very much appreciated :)
