Opened 9 years ago
Closed 8 years ago
#948 closed defect (fixed)
Web DAV module strange behaviour when client resumes upload
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | nginx-module | Version: | 1.4.x |
Keywords: | webDAV | Cc: | |
uname -a: | Linux ubuntu 3.13.0-55-generic #94-Ubuntu SMP Thu Jun 18 00:27:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux | ||
nginx -V: |
nginx version: nginx/1.4.6 (Ubuntu)
built by gcc 4.8.2 (Ubuntu 4.8.2-19ubuntu1) TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --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-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_addition_module --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_random_index_module --with-http_secure_link_module --with-http_spdy_module --with-http_sub_module --with-http_xslt_module --with-mail --with-mail_ssl_module --add-module=/build/nginx-BU0ZJt/nginx-1.4.6/debian/modules/headers-more-nginx-module --add-module=/build/nginx-BU0ZJt/nginx-1.4.6/debian/modules/nginx-auth-pam --add-module=/build/nginx-BU0ZJt/nginx-1.4.6/debian/modules/nginx-cache-purge --add-module=/build/nginx-BU0ZJt/nginx-1.4.6/debian/modules/nginx-dav-ext-module --add-module=/build/nginx-BU0ZJt/nginx-1.4.6/debian/modules/nginx-development-kit --add-module=/build/nginx-BU0ZJt/nginx-1.4.6/debian/modules/nginx-echo --add-module=/build/nginx-BU0ZJt/nginx-1.4.6/debian/modules/ngx-fancyindex --add-module=/build/nginx-BU0ZJt/nginx-1.4.6/debian/modules/nginx-http-push --add-module=/build/nginx-BU0ZJt/nginx-1.4.6/debian/modules/nginx-lua --add-module=/build/nginx-BU0ZJt/nginx-1.4.6/debian/modules/nginx-upload-progress --add-module=/build/nginx-BU0ZJt/nginx-1.4.6/debian/modules/nginx-upstream-fair --add-module=/build/nginx-BU0ZJt/nginx-1.4.6/debian/modules/ngx_http_substitutions_filter_module |
Description
With nginx web dav module, we can't resume a broken file upload correctly. Instead, the partial file on server was overwritten and only the last part was left on server finally.
To reproduce this:
1 prepare fileA, fileB, then let fileC = fileA + fileB (cat fileA fileB>fileC);
2 use curl -T fileA localhost/dav/fileA to upload the first part (which is same as fileA);
3 use curl -C lenA -T fileA fileC localhost/dav/fileA to upload the 2nd part only from the broken point
4 check server side "fileA", it is same as fileB now, but fileC is expected.
This blocks us from using web dav module as a way for resumable file uploading.
Change History (6)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Maxim,
Thanks for the quick reply... the discussions are really interesting as you mentioned.
I understand this patch can protect the partial file from being overwritten, this is nice. :)
But is there any way to achieve resumable upload after the patch with curl tool? Should one use HTTP PATCH?
Regards,
Yanfeng
comment:3 by , 9 years ago
As I said in the very first sentence of comment:1, resuming PUT requests is not something nginx supports. And PATCH isn't supported either, and as far as I understand, it is also not supported by curl
. There are no plans to add support, though feel free to suggest a patch if you are willing to implement it.
comment:4 by , 9 years ago
Priority: | blocker → minor |
---|---|
Status: | new → accepted |
comment:6 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Fix committed, thanks for reporting this.
Resuming PUT requests using the
Content-Range
header as curl does is not something nginx supports. The fact that file is silently broken looks like a bug though. RFC 2616 explicitly required to return 501 ifContent-Range
is present but not understand by the server:Newer RFC 7231 seems to assume that
Content-Range
in requests is always an error and suggests to return 400 instead:Some additional discussion can be found here (comments to the second answer are particularly interesting).
Here is a patch that ensures that nginx will return an error (501, as RFC 2616 approach looks more correct for me than RFC 7231 clearly incorrect "is likely" vision):