Forum: NGINX Upload progress module: "track_uploads" directive inside an "if" block.

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
B899fcf112f4d78022772595e99b6ce2?d=identicon&s=25 Dave Rothlisberger (drothlis)
on 2009-01-19 00:15
(Received via mailing list)
Hi,

I am using nginx as a proxy in front of a mongrel cluster running a
rails application.

I can't seem to get nginx to serve static files *and* use the upload
progress module (I can achieve one or the other, but not both at the
same time).

For example, if I use an "if" block so that requests for static files
aren't passed to the mongrel cluster:

   location / {
       ...
       if (!-f $request_filename) {
           proxy_pass http://mongrel_cluster;
           track_uploads proxied 30s;
       }
   }

This gives the following error message:

   [emerg] 12265#0: "track_uploads" directive is not allowed here

If I try, instead:

   location / {
       ...
       if (!-f $request_filename) {
           proxy_pass http://mongrel_cluster;
       }
       track_uploads proxied 30s;
   }

I get the following error message:

   [emerg] 12266#0: "track_uploads" directive track_upload should be
the last directive in the location, after either proxy_pass or
fastcgi_pass

If I remove the "if" condition completely:

   location / {
       proxy_pass http://mongrel_cluster;
       track_uploads proxied 30s;
   }

That works, but then all requests are proxied to the mongrel cluster,
even requests for static files, and even requests for the
"maintenance.html" page which I put up (with a separate rewrite rule)
when I want to take the mongrel cluster down for maintenance (rails
developers will be familiar with this). The request for the
"maintenance.html" file is sent to the mongrels, which are down,
resulting in a "502 Bad Gateway" error. And even the request for my
"50x.html" error page is proxied to the mongrel cluster (which is
down) so users get the default nginx 502 error page.

Does anyone know of a way around this, or a better way to configure
the proxy_pass to avoid this issue? Any help would be *much*
appreciated.

My full nginx config file is pasted below.

Regards,
--Dave Rothlisberger.


user xxx xxx;
worker_processes 4;

pid /var/run/nginx.pid;

error_log  logs/error.log  notice;

events {
     worker_connections  1024;
}

http {
     include       mime.types;
     default_type  application/octet-stream;

     upload_progress proxied 1m;

     # This log format is compatible with any tool like awstats
     # that can parse standard apache logs.
     log_format main '$remote_addr - $remote_user [$time_local] '
                     '"$request" $status $body_bytes_sent
"$http_referer" '
                     '"$http_user_agen" "$http_x_forwarded_for"';

     sendfile       on;
     tcp_nopush     on;
     tcp_nodelay    on;

     keepalive_timeout  65;

     gzip  on;
     gzip_http_version 1.0;
     gzip_comp_level 2;
     gzip_proxied any;
     gzip_types  text/plain text/html text/css application/x-javascript
                 text/xml application/xml application/xml+rss text/
javascript;


     # Load balance to mongrels
     upstream mongrel_cluster {
         server 0.0.0.0:8000;
         server 0.0.0.0:8001;
     }

     server {
         listen 80;
         server_name xxxx.com
         root /home/xxxx/xxxx/current/public;
         access_log /home/xxxx/xxxx/shared/log/nginx.access.log main;
         error_page 500 502 503 504 /50x.html;
         client_max_body_size 50M; # Avoid attempts to overload the
server

         # Rewrite rule: Display maintenance page if it exists
         # (capistrano disable task creates this maintenance page)
         # BUT allow the image in the maintenance page to be displayed
         if ($request_filename ~ ^/images/) {
             break;
         }
         if (-f $document_root/system/maintenance.html) {
             rewrite ^(.*)$ /system/maintenance.html last;
             break;
         }

         location / {
             index index.html index.htm;

             location ~ ^/(images|javascripts|stylesheets)/ {
                 expires 10y;
             }

             if (-f $request_filename) {
                 break;
             }

             # Directly serve cached pages
             if (-f $request_filename.html) {
                 rewrite (.*) $1.html break;
             }

             # Otherwise let mongrel handle the request
             #if (!-f $request_filename) {  # Commented because of
"track_uploads" problem
                 proxy_pass http://mongrel_cluster;
                 track_uploads proxied 30s;
             #}

             location ^~ /upload_progress {
                 report_uploads proxied;
             }
         }
     }
}
Abbd9d5312c5d54114a96a35dc94fdb1?d=identicon&s=25 Valery Kholodkov (Guest)
on 2009-01-19 01:36
(Received via mailing list)
It is because upload progress module's directives do not have flag which
  tells nginx to allow them in if block. Patch in attachment might help.
B899fcf112f4d78022772595e99b6ce2?d=identicon&s=25 Dave Rothlisberger (drothlis)
on 2009-01-19 02:49
(Received via mailing list)
Thanks for the suggestion. I've tried the patch on my staging server,
and it does indeed allow the configuration file to validate, but the
actual progress bar is not working.

With the patch, but without using an "if" block, the progress bar does
work correctly, as before.

  I will have to investigate further tomorrow as it is getting late. :-)

Cheers
Dave Rothlisberger.
B899fcf112f4d78022772595e99b6ce2?d=identicon&s=25 Dave Rothlisberger (drothlis)
on 2009-01-19 14:03
(Received via mailing list)
After further investigation, it seems that the upload progress tracker
is stuck at 'state: starting'.

(while uploading a large file, if I do a GET for /upload_progress?X-
Progress-ID=xxxx in a separate browser window, I get:

   new Object({ 'state' : 'starting' })

even a minute after it has started uploading).

Once again, this only happens if the "track_uploads" directive is
inside an "if" block; otherwise it works fine.

Regards,
Dave. Rothlisberger.
D9ce8e910f24fc5370684564c5031f1d?d=identicon&s=25 Tony Payne (lonestarsoftware)
on 2009-07-14 06:57
Dave Rothlisberger wrote:
> After further investigation, it seems that the upload progress tracker
> is stuck at 'state: starting'.
>
> (while uploading a large file, if I do a GET for /upload_progress?X-
> Progress-ID=xxxx in a separate browser window, I get:
>
>    new Object({ 'state' : 'starting' })
>
> even a minute after it has started uploading).
>
> Once again, this only happens if the "track_uploads" directive is
> inside an "if" block; otherwise it works fine.
>
> Regards,
> Dave. Rothlisberger.

I think I have found a solution to this issue. I've created a location
block that grabs the static file extensions and does the normal
processing on them without the track_uploads call. Essentially, this
means I can't track uploads to URLs ending in CSS, JS, etc. I can live
with that. It also means that full page caching probably won't work, but
I don't use that. Here's my new location block:

    location ~* \.(jpg|gif|png|css|js|htm|html)(\?[0-9]+)?$ {
      proxy_set_header  X-Real-IP  $remote_addr;
      proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $http_host;
      proxy_redirect false;
      proxy_max_temp_file_size 0;
      if (!-f $request_filename) {
        proxy_pass http://mongrel; break;
      }
    }
This topic is locked and can not be replied to.