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
Comment #1
russ0519 CreditAttribution: russ0519 commentedAlso with the module disabled, I am able to upload files (just no progress).
Comment #2
perusio CreditAttribution: perusio commentedSame 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.
Comment #3
ASupinski CreditAttribution: ASupinski commentedThis 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:
you will probably already have a location / so just add the if statement inside.
Also you no longer need the
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.
Comment #4
perusio CreditAttribution: perusio commentedThe 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.Comment #5
perusio CreditAttribution: perusio commentedThe 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.Comment #6
ASupinski CreditAttribution: ASupinski commentedThe 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.
Comment #7
perusio CreditAttribution: perusio commentedI'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
Comment #8
rogical CreditAttribution: rogical commentedsame issue
Comment #9
perusio CreditAttribution: perusio commentedWhat's your client_max_body_size? What about PHP settings?
Comment #10
rogical CreditAttribution: rogical commentedIt's 20M size, actually I'm testing upload with a small file under 3M size.
Comment #11
afeijoI'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:
also my watchdog has this error:
but I have the bellow lines
Comment #12
omega8cc CreditAttribution: omega8cc commentedPlease check the follow up: http://drupal.org/node/1592680#comment-6614400
Comment #13
omega8cc CreditAttribution: omega8cc commentedSo, we have discovered that it was wrong Nginx configuration what caused the issue for us: http://drupal.org/node/1592680#comment-6617744
Comment #14
perusio CreditAttribution: perusio commentedI just pushed a 7.x-2.0 release. Try it out and report back please. Thanks.
Comment #15
omega8cc CreditAttribution: omega8cc commentedJust 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 matchingX-Progress-ID
value.Comment #16
perusio CreditAttribution: perusio commentedThat'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
Comment #17
omega8cc CreditAttribution: omega8cc commentedWill try that, thanks.
By the way, please clean up the filefield_nginx_progress.info file, as it now references different versions:
Comment #18
omega8cc CreditAttribution: omega8cc commentedRight, so it was that missing
upload_progress_json_output;
line. Now it works. Thanks!Comment #19
perusio CreditAttribution: perusio commentedI've just commited the 2.3 version with the info file cleanup. Marking this as fixed. Thanks Grace.
Comment #20
omega8cc CreditAttribution: omega8cc commentedJust tested it again, and 7.x-2.3 works fine. Thanks!
Comment #21
descender CreditAttribution: descender commentedI'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
Comment #22
omega8cc CreditAttribution: omega8cc commented@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.Comment #23
descender CreditAttribution: descender commented@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:
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?
Comment #24
perusio CreditAttribution: perusio commented@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.
Comment #25
omega8cc CreditAttribution: omega8cc commented@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 witherror_log /var/log/nginx/error.log debug;
and study the output there.Comment #26
descender CreditAttribution: descender commentedThanks 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.
Comment #27
omega8cc CreditAttribution: omega8cc commentedPlease 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;
.Comment #28
perusio CreditAttribution: perusio commentedThanks Grace. Done!
Comment #30
JakeWilund CreditAttribution: JakeWilund commentedI'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:
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
Comment #31
perusio CreditAttribution: perusio commentedHave you declared the shared memory zone for tracking the uploads?
Note that this is to be done at the
http
level.Comment #32
JakeWilund CreditAttribution: JakeWilund commentedYep, 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.
Comment #33
perusio CreditAttribution: perusio commentedTo proceed further we need a debug log. To make sure that the correct configuration (location) is used.
Comment #34
JakeWilund CreditAttribution: JakeWilund commentedMy 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?
Comment #35
perusio CreditAttribution: perusio commentedTry adding a return directly like this and see if it prints the string.
Comment #36
alexmtl CreditAttribution: alexmtl commentedI 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.
Comment #37
perusio CreditAttribution: perusio commentedHave you check your
client_max_body_size
setting? By default is1 MB
.Comment #38
alexmtl CreditAttribution: alexmtl commentedThat 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!
Comment #39
perusio CreditAttribution: perusio commentedIt's in your nginx config.
Comment #40
rovoIncase 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) {
Comment #41
omega8cc CreditAttribution: omega8cc commented@rovo You must be using some old BOA or Aegir version, because these locations have changed in the meantime.