Question about large file uploads (100mb+)
Added by brendane almost 12 years ago
This isn't a bug or even an issue necessarily just looking to learn a bit more from the following situation, thanks in advance for any thoughts / advice you have!
So I'm running lighttpd in tandem with php on a RasberryPi, which is running Arch Linux. The problem I ran into is that when a file is uploaded through a form it is by default stored in /tmp. Since in arch /tmp is a tmpfs, on large file uploads the device runs out of RAM and starts killing processes. The obvious work around that I found was to configure lighttpd to store file uploads in a different directory. The reason I'm posting is that since these are all default configurations for well supported software I figured maybe I'm missing a very important theoretical concept here.
Thanks!
Brendan
Replies (1)
RE: Question about large file uploads (100mb+) - Added by gjmilne over 11 years ago
I have a similar issue with a custom resource-constrained device. I have a tiny /tmp that is only 2MB in size but the files I need to upload are all under 10K so that is ok for me. However, I want to handle those cases where a user accidentally picks a 700MB file by mistake.
I tried setting server.max-request-size to 16 (i.e. 16KB) and this works fine as long as the uploaded files are smaller than 2MB. However, once the files get large (e.g. > 2MB) I stop getting a 413 (request too large) error back from the server.
This issue only happens with a HTTPS connection. If I switch over to HTTP, everything works as expected (i.e. I always get a 413 back). However, I need to have this working over HTTPS.
So, I dug a bit deeper and find that SSL_Read() is returning 0 when I try to upload one of these big files. 0 is an error. The error appears to be due to a SSL_ERROR_SYSCALL but errno is reported as zero. When SSL_Read() returns 0, connection_handle_read_ssl() returns -2 to connection_handle_read_state() which causes is_closed to be set to 1. I think this is why the 413 repsonse code never gets sent back to the client.
I dug a bit deeper and see (using wireshark) that I get an encrypted alarm sent back from the server SSL layer. It looks like 0x1a but that does not appear on the Wikipedia page (http://en.wikipedia.org/wiki/Transport_Layer_Security#Alert_protocol) so I don't know how to go about fixing the problem.
Do you have any idea how I can "fix" this issue? I cannot use a bigger device partition as I do not have one available to me, on my resource constrained device.
My testing has been done with v1.4.32 on an x86 PC running Ubunta 13.04. I compiled lighttpd via the usual ./configure; make; make install route. My config is attached. I used Linux google-chrome v29.0.1547.57 for my tests. The same problems happen with Firefox and IE.
OpenSSL 1.0.1c 10 May 2012
| lighttpd.conf (10.8 KB) lighttpd.conf | config file |