upload_resume sha1, md5 and crc32 aggregates missing

Andrew Hammond andrew.george.hammond at gmail.com
Thu Oct 13 23:29:52 UTC 2011


I tested this with smaller files and see that these are never populated for
any resumable uploads.

A

On Thu, Oct 13, 2011 at 2:17 PM, Andrew Hammond <
andrew.george.hammond at gmail.com> wrote:

> So, these are available if the entire file upload happens in a single HTTP
> transaction. But if there are multiple HTTP transactions (as in resumable
> uploads) then their value is not available. Right?
>
> A
>
>
> On Tue, Oct 11, 2011 at 2:14 AM, Valery Kholodkov <
> valery+nginxen at grid.net.ru> wrote:
>
>>
>> My fault, I'll change it to "not available for resumable uploads".
>>
>> Note: body part != file segment.
>>
>> ----- Andrew Hammond <andrew.george.hammond at gmail.com> wrote:
>> > The documentation says they are supported (and for the entire uploaded
>> > file):
>> >
>> > http://www.grid.net.ru/nginx/upload.en.html#upload_aggregate_form_field
>> > *
>> >
>> > and following additional special variables:
>> > *
>> > *
>> >
>> >    - $upload_file_md5 -- MD5 checksum of the file
>> >    - $upload_file_md5_uc -- MD5 checksum of the file in uppercase
>> letters
>> >    - $upload_file_sha1 -- SHA1 checksum of the file
>> >    - $upload_file_sha1_uc -- SHA1 checksum of the file in uppercase
>> letters
>> >    - $upload_file_crc32 -- hexdecimal value of CRC32 of the file
>> >
>> > *
>> > *The value of a field specified by this directive is evaluated after
>> > successful upload of the file, thus these variables are valid only at
>> the
>> > end of processing of one part of original request body.*
>> >
>> > Since I'm seeing the following in my error log, I believe the upload was
>> > successful... so the variables should be valid, right?
>> >
>> > 2011/10/10 14:56:07 [debug] 9844#0: *91 http script var:
>> > "/var/lib/nginx/upload_resume/3/34313583"
>> > 2011/10/10 14:56:07 [info] 9844#0: *91 started uploading part
>> > 204800-209999/210000 of file "test_trans" to
>> > "/var/lib/nginx/upload_resume/3/34313583" (field "", content type
>> > "application/octet-stream"), client: 10.178.51.115, server:
>> > account.nutricateonline.com, request: "POST
>> /rspool/?id=test&sha1=00000000
>> > HTTP/1.0", host: "209.114.46.109"
>> > 2011/10/10 14:56:07 [debug] 9844#0: *91 write: 17, 00000000023D3DB7,
>> 665,
>> > 204800
>> > 2011/10/10 14:56:07 [debug] 9844#0: *91 write: 17, 00000000023CC420,
>> 4535,
>> > 205465
>> > 2011/10/10 14:56:07 [debug] 9844#0: *91 read: 17, 00000000023CAC77, 16,
>> 0
>> > 2011/10/10 14:56:07 [debug] 9844#0: *91 a 0-209999/210000
>> > 2011/10/10 14:56:07 [debug] 9844#0: *91 write: 17, 00000000023CA838, 16,
>> 0
>> > 2011/10/10 14:56:07 [info] 9844#0: *91 removed state file
>> > "/var/lib/nginx/upload_resume/3/34313583.state", client: 10.178.51.115,
>> > server: account.nutricateonline.com, request: "POST
>> > /rspool/?id=test&sha1=00000000 HTTP/1.0", host: "209.114.46.109"
>> > 2011/10/10 14:56:07 [info] 9844#0: *91 finished uploading file
>> "test_trans"
>> > to "/var/lib/nginx/upload_resume/3/34313583", client: 10.178.51.115,
>> server:
>> > account.nutricateonline.com, request: "POST
>> /rspool/?id=test&sha1=00000000
>> > HTTP/1.0", host: "209.114.46.109"
>> >
>> > I'd love to get this sorted out. Anyone?
>> >
>> > Andrew
>> >
>> >
>> > On Sat, Oct 8, 2011 at 8:55 AM, Valery Kholodkov <
>> valery+nginxen at grid.net.ru
>> > > wrote:
>> >
>> > >
>> > > These aggregates are not available for resumable uploads, as hashes of
>> the
>> > > last part will not make sense anyway.
>> > >
>> > > ----- Andrew Hammond <andrew.george.hammond at gmail.com> wrote:
>> > > > I'm seeing most, but not all of the upload form fields get set.
>> However,
>> > > the
>> > > > sha1, md5 and crc32 aggregates below are blanks:
>> > > >
>> > > > request.POST <QueryDict: {
>> > > > u'upload_name': [u'py_lightweight_uploader.py'],
>> > > > u'upload_size': [u'11345'],
>> > > > u'upload_sha1': [u''],
>> > > > u'upload_content_type': [u'text/x-python'],
>> > > > u'upload_path': [u'/var/lib/nginx/resumable_download/7/64565707'],
>> > > > u'upload_md5': [u''],
>> > > > u'upload_crc32': [u'']}>
>> > > >
>> > > > I see that libssl is installed on the server. I don't see any
>> entries in
>> > > the
>> > > > error log that would make me think there is anything failing here. I
>> have
>> > > > the following in the nginx config:
>> > > >
>> > > > upload_set_form_field upload_name $upload_file_name;
>> > > > upload_set_form_field upload_content_type $upload_content_type;
>> > > > upload_set_form_field upload_path $upload_tmp_path;
>> > > > upload_aggregate_form_field upload_sha1 $upload_file_sha1;
>> > > > upload_aggregate_form_field upload_size $upload_file_size;
>> > > > upload_aggregate_form_field upload_crc32 $upload_file_crc32;
>> > > > upload_aggregate_form_field upload_md5 $upload_file_md5;
>> > > >
>> > > > I based the above on the documentation and example config. What am I
>> > > missing
>> > > > here? I'm using nginx 1.0.8 deb-src build from the PPA with the
>> latest
>> > > > version of the upload_resume module included.
>> > >
>> > > --
>> > > Regards,
>> > > Valery Kholodkov
>> > >
>> > > _______________________________________________
>> > > nginx mailing list
>> > > nginx at nginx.org
>> > > http://mailman.nginx.org/mailman/listinfo/nginx
>> > >
>>
>> --
>> --
>> Regards,
>> Valery Kholodkov
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20111013/28d27a93/attachment-0001.html>


More information about the nginx mailing list