Opened 5 years ago
Closed 5 years ago
#1858 closed defect (worksforme)
uWSGI params Content length issue when uploading file
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | minor | Milestone: | nginx-1.17 |
Component: | other | Version: | 1.17.x |
Keywords: | Nginx upload module | Cc: | |
uname -a: | Linux samh-OptiPlex-5060 5.0.0-29-generic #31~18.04.1-Ubuntu SMP Thu Sep 12 18:29:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux | ||
nginx -V: |
nginx version: nginx/1.17.3 (Ubuntu)
built by gcc 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1) built with OpenSSL 1.1.1c 28 May 2019 TLS SNI support enabled configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/run/nginx.pid --lock-path=/var/lock/nginx.lock --user=www-data --group=www-data --build=Ubuntu --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-openssl=../openssl-1.1.1c --with-openssl-opt=enable-ec_nistp_64_gcc_128 --with-openssl-opt=no-nextprotoneg --with-openssl-opt=no-weak-ssl-ciphers --with-openssl-opt=no-ssl3 --with-pcre=../pcre-8.43 --with-pcre-jit --with-zlib=../zlib-1.2.11 --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_slice_module --with-http_ssl_module --with-http_sub_module --with-http_stub_status_module --with-http_v2_module --with-http_secure_link_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-debug --add-module=/home/samh/Downloads/nginx-upload-module-master --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' |
Description
Hello,
Working on 1.17 and using Nginx Upload Module I have come across a small bug. Perhaps only relevant to the 3rd party module but I have not had the time to check the source code. Apologies.
Have a look at the config below which does work. Basically, if the uwsgi params variable CONTENT_LENGTH (last line) is stored in the uwsgi params file and then included, I run into problems.
I have a flask app behind uWSGI and when I call request.form it hangs. This is after the 3rd party module strips the file from the body. However, it was not changing the content length. flask.request.form was waiting for further bytes to close off the request. As you can see I have declared it separately.
location /upload/ {
auth_request /upload_auth/;
upload_pass @uploads;
upload_store (redacted)
upload_store_access all:rw;
upload_set_form_field $upload_field_name.name "$upload_file_name";
upload_set_form_field $upload_field_name.content_type "$upload_content_type";
upload_set_form_field $upload_field_name.path "$upload_tmp_path";
upload_pass_form_field "FileName$|File$|path$|name$|test$";
}
location @uploads {
uwsgi_pass (redacted)
uwsgi_pass_request_body on;
include /etc/nginx/uwsgi_params;
uwsgi_param CONTENT_LENGTH $content_length;
}
Kind regards,
SH
As long as the module you are using changes the request body, it is highly likely that $content_length value is incorrect. It is up to the module to make sure it is correct, and it might be non-trivial to achieve this - in particular, due to caching of variable values.
There should be no difference between
uwsgi_param CONTENT_LENGTH $content_length;
in the included file and the same configuration directive in the config itself. There can be significant difference, though, if theuwsgi_params
file is used elsewhere - in particular, in theauth_request
processing, as this can result in$content_length
variable value being cached before it is modified by the module.If you think that there is a difference between
uwsgi_param
in the included file and the same configuration directive in the config itself (and the file in question is not used elsewhere, so the behaviour cannot be explained by caching), please provide full configuration (as shown bynginx -T
) which demonstrates the problem and a debug log of a failed request, as well as a configuration which does not have the problem and a debug log of successful request.