Changes (2008-08-06):
- Fixed bug: location configuration of upload_set_form_field and
upload_pass_form_field was not inheritable from server configuration.
- Added feature: directive upload_aggregate_form_field to pass
aggregate properties of a file like file size, MD5 and SHA1 sums to
backend.
- Fixed bug: missing CRLF at the end of resulting body.
- Change: optimized out some unnecessary memory allocations and
zeroing.
See module page for details:
http://www.grid.net.ru/nginx/upload.en.html
I also have found that there are no issues with interaction between
upload module and upload progress module, so they could be nicely used
together.
On 8/6/08, Valery K. [email protected] wrote:
Hi there - how could this work with PUT method?
Basically I need to be able to PUT files of various sizes - from a few
bytes to 2GB, maybe more someday.
We’d like the webserver to accept it via PUT and then feed the
location of the file to PHP so PHP can do the post processing (file
rename, input the metadata into database, etc.)
I want to use nginx for this. Not sure if a third party module like
yours is required or not. Right now, I can do a simple single file PUT
to a php script and use php://input to open the stream. However large
files will consume all the PHP script resources I believe if it has to
accept all the data (unless the upload client is smart enough to spoon
feed it in certain chunks…)
Is this understandable? I’ve kind of gone off the deep end here now.
mike ha scritto:
On 8/6/08, Valery K. [email protected] wrote:
Hi there - how could this work with PUT method?
You don’t need this module, if the request body contains the whole file.
The upload module is usually useful for POST requests, since the request
body is multipart/form-data encoded, when sent by browsers.
If you are using PUT, then probably the client is under your control.
files will consume all the PHP script resources I believe if it has to
accept all the data (unless the upload client is smart enough to spoon
feed it in certain chunks…)
This is not what the upload module does: the upload module has been
written for decoding multipart/form-data request bodies “on the fly”.
If the file is very large, there is nothing that can be done now.
How do you read the file from PHP?
If you don’t have to read the whole file (as it usually is), then this
should not be a big problem.
As an example, for renaming the file, you don’t need to read the file
from PHP: let Nginx store the file in a temporary file and just rename
that file.
Is this understandable? I’ve kind of gone off the deep end here now.
Manlio P.
On 8/6/08, Manlio P. [email protected] wrote:
How do you read the file from PHP?
well right now php://input - it comes through via stdin
As an example, for renaming the file, you don’t need to read the file from
PHP: let Nginx store the file in a temporary file and just rename that file.
okay so i need to tune nginx to accept large client uploads…
mike [email protected] wrote:
Hi there - how could this work with PUT method?
It can’t. Use built in DAV module.
Is this understandable? I’ve kind of gone off the deep end here now.
In this way even DAV module can’t do it, I suppose. Why are not happy
with
POST?
On 8/7/08, Valery K. [email protected] wrote:
POST?
POST isn’t reliable for large files and I don’t believe (without some
major inspection) it can support resuming files, etc.
PUT seems like the appropriate method for large files, and skipping
the encoding step. I already have a PHP script which will process it
too, and tons of different browser applets to choose from that will
handle it.
People will be uploading files of various sizes from various
connection speeds and geographies, so it has to support resuming,
gracefully from timeouts or hitting the pause button etc.
It does not seem like POST will do that; not to mention the server
handles POST differently than PUT.
I believe nginx’s DAV support will work just need to test out large
files, pick a specific upload applet, etc.
mike [email protected] wrote:
handles POST differently than PUT.
I believe nginx’s DAV support will work just need to test out large
files, pick a specific upload applet, etc.
I agree with you. The proper uploader should be able to handle partial
uploads. This would be a nice challenge for me to implement chunked
transfer encoding and byte ranges support for PUT.
May be I’ll consider this later.
On 8/7/08, Valery K. [email protected] wrote:
I agree with you. The proper uploader should be able to handle partial
uploads. This would be a nice challenge for me to implement chunked
transfer encoding and byte ranges support for PUT.
May be I’ll consider this later.
PUT already can accept byte ranges more or less - the client just has
to tell the script (PHP for example) something like
put.php?offset=123456 - and then in php you fseek($fp, $offset) and
resume filling in the content from there.
It takes a smart client to know where it left off though. That’s one
thing I don’t know exactly how it works.
Here’s an example product:
http://www.radinks.com/upload/
http://www.radinks.com/upload/plus/resume.php - their little marketing
bit about upload resuming
http://www.radinks.com/upload/examples/resume.php.txt - the PHP script
they provide as an example