I have the latest nginx (1.0.2) with latest Nginx Upload Progress Module (0.8.2) compiled. The upload progress itself seems to work well. There are several issues (some which may be as designed):

I'm getting the following in the status report:

Upload progress Not enabled
Your server is not capable of displaying file upload progress. File upload progress requires an Apache server running PHP with mod_php.
Upload progress nginx Enabled (upload progress module )

I also see no way to enable the progress bar.

The biggest issue, however, is that the file actually fails to upload. I'm getting the following error:

An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (512MB) that this server supports.

Doing a bit of it seems that this error is coming from the file module, specifically line 235:
if (empty($_POST['form_build_id']) || $form_build_id != $_POST['form_build_id']) {
// Invalid request.
drupal_set_message(t('An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (@size) that this server supports.', array('@size' => format_size(file_upload_max_size()))), 'error');
$commands = array();
$commands[] = ajax_command_replace(NULL, theme('status_messages'));
return array('#type' => 'ajax', '#commands' => $commands);
}

Changing that code to be:

if (empty($_POST['form_build_id'])) {
// Invalid request.
drupal_set_message(t('An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (@size) that this server supports. form_build_id was empty', array('@size' => format_size(file_upload_max_size()))), 'error');
$commands = array();
$commands[] = ajax_command_replace(NULL, theme('status_messages'));
return array('#type' => 'ajax', '#commands' => $commands);
}

if ($form_build_id != $_POST['form_build_id']) {
// Invalid request.
drupal_set_message(t('An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (@size) that this server supports. Expected form_build_id was ' . $form_build_id . ' but received ' . $_POST['form_build_id'], array('@size' => format_size(file_upload_max_size()))), 'error');
$commands = array();
$commands[] = ajax_command_replace(NULL, theme('status_messages'));
return array('#type' => 'ajax', '#commands' => $commands);
}

I get the following error:

An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (512 MB) that this server supports. Expected form_build_id was x-progress-id:1359761421 but received form-kRypYhCuFTeXjT2aC7J6tkggwr4N2TM9tPHHAnQ3w5M

It seems that this line:
$form_build_id = (string) array_pop($form_parents);
is getting x-progress-id:1359761421 when it's expecting to get form-kRypYhCuFTeXjT2aC7J6tkggwr4N2TM9tPHHAnQ3w5M.

Is this a bug that needs to be fixed, or is my configuration screwed up somehow?

Comments

russ0519’s picture

Also with the module disabled, I am able to upload files (just no progress).

perusio’s picture

Same here. It fails. I tried both with and without the overlay. I'm also using nginx 1.0.2. I'll try to see what's going on later.

ASupinski’s picture

This is a side affect of how Drupal 7's ajax is sending information no longer working with how this module currently recommends you set up nginx. I have successfully gotten the progress bar to work by:
1. applying the patch near the end of #935208: PECL uploadprogress bar doesn't appear.
2. Change your nginx configuration to include the following:

        location / {
			if ($args ~* (.*)/x-progress-id%3A(\w*)) {
				set $args $1&X-Progress-ID=$2;
			}
        }

you will probably already have a location / so just add the if statement inside.
Also you no longer need the

	location ~ (.*)/x-progress-id:(\w*) {
            rewrite ^(.*)/x-progress-id:(\w*)  $1?X-Progress-ID=$2;
        }

recommended by the module readme. If you do this the file code will work correctly since Nginx will once more be doing the required rewrite.

perusio’s picture

The patch you referenced doesn't work.

Also your suggested way of doing things, i.e., by changing the $args variable is one of the things that this module aims to avoid. It's rather ugly and it introduces an unnecessary rewrite phase directive. Since it's inside the '/' location it will always be run whenever that location is selected. Since that's the catch-all location it's a lot of times.

perusio’s picture

The form is not being correctly rebuilt, it seems. Something is missing in filefield_nginx_progress_element_process. I haven't got time now to investigate further.

ASupinski’s picture

The patch is certainly not necessary in the latest version of core but it was working for my installation previously. Also perhaps the args rewriting might not be generally necessary but I am seeing many of the links in my d7 installation use the q= rather than the clean paths so this was a work around.

perusio’s picture

Assigned: Unassigned » perusio

I'll have a look at this during this week. BTW, can anyone tell me if the Apache version of the upload progress bar is working? I have been told that it doesn't work. This module adapts the code that is used for the upload progress bar in Apache. So if it fails there it will also fail here.

Thanks

rogical’s picture

same issue

An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (20 MB) that this server supports.

perusio’s picture

What's your client_max_body_size? What about PHP settings?

rogical’s picture

It's 20M size, actually I'm testing upload with a small file under 3M size.

afeijo’s picture

I'm having the same problem
with the module enabled, an error shows up that the file is too big
the file I'm testing is only 300 kb, the limit is set to 50mb in both php and nginx

I noticed this error in the watchdog:

Notice: Undefined offset: 1 em nginx_progress_fetch() (line 123 de /www/sites/all/modules/filefield_nginx_progress/filefield_nginx_progress.module).

also my watchdog has this error:

page not found         progress

but I have the bellow lines

server {
  location ^~ /progress {
    report_uploads uploads;
  }
}
omega8cc’s picture

Priority: Major » Critical
omega8cc’s picture

Priority: Critical » Major

So, we have discovered that it was wrong Nginx configuration what caused the issue for us: http://drupal.org/node/1592680#comment-6617744

perusio’s picture

I just pushed a 7.x-2.0 release. Try it out and report back please. Thanks.

omega8cc’s picture

Version: 7.x-1.x-dev » 7.x-2.1

Just tried 7.x-2.1 and it doesn't work on the same site, where 7.x-1.x-dev worked fine. I probably missed something obvious, as I didn't try 7.x-2.x before, always 7.x-1.x, but I don't see any difference mentioned for the Nginx config, other than new rewrite, which does basically the same, just changing D6 compatible \w to D7 only compatible \d for matching X-Progress-ID value.

perusio’s picture

That's strange. It works for me here. Can you try the 7.x-2.x-dev version? I changed the way the JSON is decoded. The 1.x version does a manual decoding and the 2.x version uses json_decode. Note that to use the 7.x-2.x version you have to add upload_progress_json_ouptut to the /progress location.

Grab it from github please: https://github.com/perusio/filefield-nginx-progress

omega8cc’s picture

Will try that, thanks.

By the way, please clean up the filefield_nginx_progress.info file, as it now references different versions:

; Information added by drupal.org packaging script on 2011-02-25
version = "7.x-1.x-dev"
core = "7.x"
project = "filefield_nginx_progress"
datestamp = "1298619258"


; Information added by drupal.org packaging script on 2012-10-21
version = "7.x-2.1"
core = "7.x"
project = "filefield_nginx_progress"
datestamp = "1350828109"
omega8cc’s picture

Status: Active » Reviewed & tested by the community

Right, so it was that missing upload_progress_json_output; line. Now it works. Thanks!

perusio’s picture

Status: Reviewed & tested by the community » Fixed

I've just commited the 2.3 version with the info file cleanup. Marking this as fixed. Thanks Grace.

omega8cc’s picture

Just tested it again, and 7.x-2.3 works fine. Thanks!

descender’s picture

I've had to hack file_ajax_upload() as described here to remove the spurious "Unrecoverable error" generated each time an upload finishes.

Is there anyone who's had the error removed without this hack? If not, it might be good to document this on the project page.

Edit: this is with the latest 2.3 update

omega8cc’s picture

@descender if you need to hack file_ajax_upload() then you have something to fix in your Nginx config, probably? I don't see this error with our latest Nginx config used in BOA and 2.3 update.

descender’s picture

@omega8cc, thanks for the pointer. I believe you're right. On further debugging, I noticed that the POST request URI at the end of each upload <FORM-URI>/x-progress-id:<ID> is not being rewritten to <FORM-URI>?X-Progress-ID=<ID>. This happens despite of this rule in the config:

location ~ (?<upload_form_uri>.*)/x-progress-id:(?<upload_id>\d*) {
  rewrite ^ $upload_form_uri?X-Progress-ID=$upload_id;
}

My current nginx config is a simplified version of perusio's. As far as I can tell, its only significant difference from the BAO config (and the one by yhager) is that the latter performs an additional rewrite to transform clean URIs into index.php?q=$uri. Mine doesn't. Could this be related?

perusio’s picture

@descender are you sure that this location is not being used by Nginx? That means that somehow the element process callback is not being invoked. Can you verify that? Thanks.

omega8cc’s picture

@descender also, I have posted a summary of what was wrong in our BOA Nginx config here: http://drupal.org/node/1592680#comment-6622896

I hope this will offer some hints. I don't think that index.php?q=$uri stuff could be related.

I would recommend to have Nginx built with --with-debug option, then enable debugging with error_log /var/log/nginx/error.log debug; and study the output there.

descender’s picture

Thanks perusio and omega8cc, I want to say your support is very encouraging. I haven't had time in the past few days to take a second look - the file module hack suffices as a temporary workaround - but I will in the days to come.

omega8cc’s picture

Please see also: http://drupal.org/node/1837910#comment-6719966

This should be added to the module how-to, because D6 version since 0.9.0 requires extra, but different directive: upload_progress_java_output;.

perusio’s picture

Thanks Grace. Done!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

JakeWilund’s picture

I'm experiencing the same error as the original poster. I've tried to sift through this thread as best I can, but I'm unable to find anything that seems to fix the issue. I am currently running the latest stable release (7.x-2.3) and am seeing the "An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (20MB) that this server supports."

When starting an upload, I do see the progress bar, but it never actually seems to move off it's initial position (just stays stuck until the file finishes uploading, at which point the error occurs).

I've added the track_uploads uploads 60s; line to the "location ~ \.php$" location. Here's what my config looks like:

location ~ \.php$ {
		fastcgi_index   index.php;
		fastcgi_pass    127.0.0.1:9000;
		#fastcgi_pass   unix:/var/run/php-fpm/php-fpm.sock;
		include         fastcgi_params;
		fastcgi_param   SCRIPT_FILENAME    $document_root$fastcgi_script_name;
		fastcgi_param   SCRIPT_NAME        $fastcgi_script_name;
		track_uploads uploads 60s;
	}
## Drupal 7 config.
	location ~ (?<upload_form_uri>.*)/x-progress-id:(?<upload_id>\d*) {
		rewrite ^ $upload_form_uri?X-Progress-ID=$upload_id;
	}
	
	location ^~ /progress {
		upload_progress_json_output; 
		report_uploads uploads;
	}

I know Nginx is configured with the upload progress module, as I rebuilt it from source this morning (previously had installed via yum, so had to rebuild to include the upload progress module).

Here is the result of "nginx -V":

nginx version: nginx/1.2.6
built by gcc 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC)
TLS SNI support enabled
configure arguments: --sbin-path=/usr/local/sbin --with-http_ssl_module --add-module=src/misc/nginx-upload-progress-module

perusio’s picture

Have you declared the shared memory zone for tracking the uploads?

## Define a zone named uploads with a 1MB size.
upload_progress uploads 1m;

Note that this is to be done at the http level.

JakeWilund’s picture

Yep, I do have that in my primary nginx config file at the http level. I should have included that bit of info in my post.

perusio’s picture

To proceed further we need a debug log. To make sure that the correct configuration (location) is used.

JakeWilund’s picture

My debug log is empty. It looks like I didn't build Nginx with the -with-debug option. I'm still fairly new to linux, so rebuilding Nginx isn't something I really want to have to tackle, but I will if I have to. Is there anything else that I might try before doing this?

perusio’s picture

Try adding a return directly like this and see if it prints the string.

location ~ (?<upload_form_uri>.*)/x-progress-id:(?<upload_id>\d*) {
     return 200 "$upload_form_uri?X-Progress-ID=$upload_id\n";
    #rewrite ^ $upload_form_uri?X-Progress-ID=$upload_id; 
}
alexmtl’s picture

Status: Closed (fixed) » Active

I have the same issue... weird thing is... this module is not installed on my site. I get this message :

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /file/ajax/field_rapport_final/und/0/form-BAO3_oD7c4AZWpU8XwKrg40j50oxc_pVpPvc0RTT4RM
StatusText: n/a
ResponseText: 413 Request Entity Too Large
nginx
ReadyState: undefined

Backed up the entire site, run it on a local machine, and it does not occur. I tested and the error only occurs with over 1 MB files (which I deal with quite a lot). That lead me to the conclusion that it could be on my host's side. He experienced a crash and had to reinstall stuff.

.htaccess has these settings :
php_value post_max_size 130M
php_value upload_max_filesize 8M
php_value memory_limit 96M

phpinfo.php returns these values :
post_max_size 8M 8M
upload_max_filesize 128M 128M

I don't know if I post in the right section or not... but apparently all my searches return to this post. I'm not a developper by any means... Be gentle :D

All help is appreciated.

perusio’s picture

Status: Active » Closed (fixed)

Have you check your client_max_body_size setting? By default is 1 MB.

alexmtl’s picture

That setting does not show up in phpinfo or in the .htaccess file. Where should I add it ? if that is the only thing I need to change, it would be AWESOME!

perusio’s picture

It's in your nginx config.

rovo’s picture

Incase it helps anyone else, I had to another step not emphasized here, but mentioned by Omega on another thread.

On my Aegir setup I have a nginx_advanced_include.conf file.

Changed:
location ~* /(?:autocomplete|ajax|ahah)/ {

To:
location ~* /(?:autocomplete|ahah|batch) {

omega8cc’s picture

@rovo You must be using some old BOA or Aegir version, because these locations have changed in the meantime.