Nginx: unknown directive "upload_pass" after dist-upgrade from Ubuntu 12.04 LTS to 14.04 LTS

Server NGINX
1

Hello!

I performed a dist-upgrade, from Ubuntu 12.04 LTS to 14.04 LTS, and once
the dust had settled, nginx refused to start with:

nginx: [emerg] unknown directive “upload_pass” in
/etc/nginx/sites-enabled/example.com.vhost:95

The “upload_pass” directive appears to be part of the HttpUploadModule.
This module was clearly installed before the dist-upgrade, because the
vhost in question functioned as expected before applying the upgrade.

It is not clear which Ubuntu package includes this module. I figured,
“What the hell…” and installed nginx-extras, which is supposed to
include all of the most commonly used modules, yet the problem persists.

It seems unlikely that the name of this directive changed. What other
explanations are there?

Thanks for any ideas! Full configuration provided below.

-Ben

nginx -V

nginx version: nginx/1.6.0
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_auth_request_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/buildd/nginx-1.6.0/debian/modules/headers-more-nginx-module
–add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-auth-pam
–add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-cache-purge
–add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-dav-ext-module
–add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-development-kit
–add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-echo
–add-module=/build/buildd/nginx-1.6.0/debian/modules/ngx-fancyindex
–add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-http-push
–add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-lua
–add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-upload-progress
–add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-upstream-fair
–add-module=/build/buildd/nginx-1.6.0/debian/modules/ngx_http_substitutions_filter_module

2

On Thursday 21 August 2014 21:02:43 Ben J. wrote:

vhost in question functioned as expected before applying the upgrade.

It is not clear which Ubuntu package includes this module. I figured,
“What the hell…” and installed nginx-extras, which is supposed to
include all of the most commonly used modules, yet the problem persists.

It seems unlikely that the name of this directive changed. What other
explanations are there?

[…]

This 3rd-party module was removed from the package, because it’s broken
and
cannot be compiled with the newer versions of nginx.

See:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729003

wbr, Valentin V. Bartenev

3

On 8/21/2014 9:02 PM, Ben J. wrote:

nginx -V

nginx version: nginx/1.6.0

I should add also that immediately after the upgrade from version 12.04
to 14.04 of my OS, this problem was present, and my nginx version was
1.4.6. The reason for which my current config (quoted above) shows 1.6.0
is that I followed these instructions when trying to build nginx with
every module I have needed in the past, in an effort to troubleshoot
this problem:

What’s puzzling me most is that I only ever remember having to install
the NGINX Upload Progress Module | NGINX in any “special way”.
And by “special way”, I think I simply switched from Ubuntu’s
“nginx-core” to “nginx-extras” package when first I “got everything
working”.

Is this module ( Upload | NGINX , to which the
“upload_pass” directive applies) built into the core of nginx? I ask
mostly because when I built nginx from source (the 1.6.0 version), the
“extras” config section mentions nothing of the module in question
(that’s causing the fatal upon nginx start-up):

(from “nginx-1.6.0/debian/rules”):

…

extras_configure_flags :=
$(common_configure_flags)
–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=$(MODULESDIR)/headers-more-nginx-module
–add-module=$(MODULESDIR)/nginx-auth-pam
–add-module=$(MODULESDIR)/nginx-cache-purge
–add-module=$(MODULESDIR)/nginx-dav-ext-module
–add-module=$(MODULESDIR)/nginx-development-kit
–add-module=$(MODULESDIR)/nginx-echo
–add-module=$(MODULESDIR)/ngx-fancyindex
–add-module=$(MODULESDIR)/nginx-http-push
–add-module=$(MODULESDIR)/nginx-lua
–add-module=$(MODULESDIR)/nginx-upload-progress
–add-module=$(MODULESDIR)/nginx-upstream-fair
–add-module=$(MODULESDIR)/ngx_http_substitutions_filter_module

…

I see the line for the “HttpUploadProgressModule”, as described at
NGINX Upload Progress Module | NGINX , but this is a different
module, correct?

Thanks again for any assistance,

-Ben

4

On 8/22/2014 3:05 AM, Valentin V. Bartenev wrote:

This module was clearly installed before the dist-upgrade, because the

This 3rd-party module was removed from the package, because it’s broken and
cannot be compiled with the newer versions of nginx.

See:
Bug #1177719 “Nginx 1.4.0 extras missing upload module” : Bugs : Nginx
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729003

wbr, Valentin V. Bartenev

Thank you kindly, Valentin. That explains it!

Well, that’s a real disappointment. Is it no longer possible for nginx
to handle uploads in a similar manner? This was one of my favorite
features of nginx: the ability to offload large file uploads from PHP
onto nginx.

Sadly, until I can find a comparable solution to the problem of
uploading massive (2GB+) files without needing to leverage a server-side
scripting language, such as PHP, I have little choice but to stick to
obsoleted versions of nginx that support this module.

I am eager to hear how others have dealt with this most useful module’s
disappearance…

Thanks again, Valentin.

-Ben

5

On 8/22/2014 7:12 PM, Valentin V. Bartenev wrote:

[…]
fastcgi_pass_request_body off;
Module ngx_http_core_module
Module ngx_http_core_module

wbr, Valentin V. Bartenev

nginx mailing list
[email protected]
nginx Info Page

Hello,

I apologize for the 4-month delay in responding. :slight_smile:

In particular, I need to have the ability to track upload progress in a
manner that is conducive to displaying the percentage complete via
progress bar.

Is this still possible, absent the defunct module at
NGINX Upload Progress Module | NGINX ?

Thank you!

-Ben

6

On Saturday 13 December 2014 18:58:54 Ben J. wrote:
[…]

You can easily implement it on the browser side using the progress
events
of XMLHttpRequest, which is supported by all modern browsers.

wbr, Valentin V. Bartenev

7

On Friday 22 August 2014 17:54:22 Ben J. wrote:
[…]

Thank you kindly, Valentin. That explains it!

Well, that’s a real disappointment. Is it no longer possible for nginx
to handle uploads in a similar manner? This was one of my favorite
features of nginx: the ability to offload large file uploads from PHP
onto nginx.

[…]

Could you elaborate a bit what’s the ability you’re speaking about?

By default, nginx is good enough in offloading large file uploads.

For example:

location /upload {
fastcgi_pass backend;

  fastcgi_pass_request_body off;
  fastcgi_param UPLOADED_FILENAME $request_body_file;

  client_body_in_file_only on;

}

With the configuration above nginx only passes the name of the
uploaded file.

Reference:
http://nginx.org/r/fastcgi_pass_request_body
http://nginx.org/r/client_body_in_file_only
http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_body_file

wbr, Valentin V. Bartenev

8

On 12/13/2014 7:10 PM, Valentin V. Bartenev wrote:

Is this still possible, absent the defunct module at
NGINX Upload Progress Module | NGINX ?

You can easily implement it on the browser side using the progress events
of XMLHttpRequest, which is supported by all modern browsers.

wbr, Valentin V. Bartenev

Thank you for the continued assistance, Valentin.

With regard to implementing upload progress tracking on the client side,
two concerns come to mind:

1.) The inability to resume file uploads (is this possible with a
100%-client-side implementation?)

2.) Progress reporting accuracy, in the event that upload resumption is
even possible with a client-side-only implementation

I’m dealing with sizable files (in excess of 1GB), and I really need to
support upload resumption when an upload attempt fails for any reason.

It’s not clear whether client-side upload progress tracking would be
able to display an accurate progress bar when, say, only 50% of the file
must be uploaded during a given attempt.

Currently, I am using Nginx upload module (v 2.2.0) with Nginx HTTP
Upload Progress module, which, in combination, do everything that I
require.

I really wish that these modules could be made to work with the newest
versions of NGINX. I’m curious if we’re talking a couple of small
“tweaks”, or if these modules would need to be largely rewritten to work
with the latest versions of NGINX.

Thanks again for sharing your valuable insights.

-Ben