I had a small conversation with the downstream maintainer of the Debian package and he mentioned there is a watch file in the Debian package which reports new releases given tagged versions of the source.

Since there have been major changes recently which qualify for a new release I'd suggest to test the current source base, merge outstanding changes to the main repository and tag a new release version.

I still have some local changes that aren't pushed yet, but once they are I'll notify you with a pull request.

Please also do a security audit of the code base to check for issues which might be exploited or impact the stability of the module.

Output of the /progress with the ID of the upload:

{ "state" : "starting" }

always, even when finished.

It does not compile on Snow Leopard. There are several warnings: "missing required architecture ppc64 in file".

When using the latest apache upload progress module (with changes as recent as 5-21-09) about 30% of uploads fail with a message like the following in the apache error_log:

[Wed Jul 15 15:45:23 2009] [notice] child pid 29196 exit signal Segmentation fault (11)

Requesting the progress after this happens with the corresponding X-Progress-ID continually returns a status of "starting".

I am running:
Apache 2.2.11
w/ Passenger 2.2.4/Rails 2.3.2

I'm also using mod_rewrite and mod_xsendfile along with the default enabled modules of Apache.

I tried recompiling with --enable-exception-hook and loading mod_whatkilledus to get more info (per http://www.techds.in/2009/02/debugging-notorious-segmentation-fault.html) but was unable to gather any more useful information.

Recompiled again without --enable-exception-hook but kept the --enable-nonportable-atomics=yes option and the upload failures continue, but the corresponding error log entries now look like this:

*** glibc detected *** double free or corruption (out): 0x086f9b08 ***
[Fri Jul 17 10:25:46 2009] [notice] child pid 6633 exit signal Aborted (6)

When I disable mod_upload_progress, uploading works consistently again.

Sorry I can not provide more helpful information.

• Jonn

Hi,

It seems that mod_upload_progress returns invalid content type in the header of the returned progress status "/progress". It sets "text/javascript" (see line 711 in mod_upload_progress.c) and according this this thread:
http://stackoverflow.com/questions/477816/the-right-json-content-type it should be "application/json".

This might bring problems to some JS-applications which try to validate response data basing on its header. For example firefox+righjs-uploader (http://rightjs.org/ui/uploader) would generate "invalid label" error when tries to handle response from mod_upload_progress - which is correct, cause it tries to handle returned value as javascript and not as plain json.

That was ok for the older version of mod_upload_progress (http://piotrsarnacki.com/2008/06/18/upload-progress-bar-with-mod_passenger-and-apache/) which returned json like this:

new Object({ ‘state’ : ‘starting’ })

new Object(...) directive allowed validator not to generate "invalid label" error.

Now with plain json:
{ ‘state’ : ‘starting’ }

it gives problems.

After upgrading to Debian 11 (bullseye) apache would intermittently crash during nightly log rotation with the following message in error.log:

[Tue Jan 04 00:00:01.109918 2022] [:error] [pid 2876161] (17)File exists: Upload Progress cache: could not create shared memory segment
[Tue Jan 04 00:00:01.109952 2022] [:emerg] [pid 2876161] AH00020: Configuration Failed, exiting

I've found a workaround and opened a PR that fixes this in my deployment:
#36

Any plans for an nginx module? Or is there a way to track upload progress with Passenger/Nginx?

Hello, i'm using apache22 with mod_uploadprogress on freebsd (also had this problem on centos). The upload status only shows me the size, and the state, speed and recieved are 0, i am posting to a .php script with basic file upload manipulation. Also i tested with a perl and python script in the cgi mode and the status worked fine. PHP is working in fastcgi, might fastcgi be the problem?

Hello!

I use the module on two web balanced apache server (with passenger, and not simulated through apache but real server), and it seems there is a problem when calling the URL to progress, I doubt that sometimes the call is handled by the "wrong" server (not the same that is handling the current upload), which cause progress to never complete... hum.

Well, how can I handle that? Share ideas please ;)

Thanks!

I think should put this issue in the README file, or fix it.

The current release of mod_upload_progress.c does not work with Apache2.0. Due to lack of apr_shm_remove in apxs.
However a patch available from mod_fastcgi for this and applied to the module works. Tested on 2.0.63

http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2007-June/122731.html

When trying to set up a Location context global to all VHosts the configuration gets ignored:

<Location />
    TrackUploads on
</Location>

<Location /uploadstatus>
    ReportUploads on
</Location>

NameVirtualHost 192.168.0.1:80
<VirtualHost 192.168.0.1:80>
    ServerName example.com
    ServerAlias example.net
    DocumentRoot /var/www
</VirtualHost>

Will return a 404 on http://example.com/uploadstatus?X-Progress-ID=foobarbaz

Putting both location blocks into the VirtualHost context makes this example work.

Expected behaviour: Global Location block sets defaults which are updated by VHost specific configurations.

When rechecking the apache module against the demo page I found an issue with commit 568e breaking the script; everything before this on my master works, but the parameter rename breaks the module. Reverting for now on my master for clean reintegration.

When trying to compile the source package with the Git repository overlapped I get a compile error from the dh helper scripts. When I remove the Makefile the error is gone and the deb package builds correctly. If I execute the makefile directly it works fine too, but I don't get the deb file from it.

Would be nice if someone could have a look at it.

I'm using apt-src build libapache2-mod-upload-progress for invokation. To prepare:

• Enable Squeeze sources in sources.list (Lenny doesn't have the package at all)
• cd /directory/where/you/want/to/have/the/source/files
• apt-src install libapache2-mod-upload-progress
• git clone [email protected]/... tmp
• Move all contents from the Git repository over the directory with the source package
• cd out of the source directory if necessary
• apt-src build libapache2-mod-upload-progress (will fail, unless the Makefile is removed from the source directory)

Anyone some idea on how to make the Makefile compatible with dpkgbuildpackage?

There should be some constraints applied to allowable ProgressIDs for this module to work around or avoid XSS risks and DoS attack vectors.

I'd suggest the following constrains:

• Maximum length: 40 chars
• Minimum length: 8 chars (to force security against easy guessing)
• Allowable chars: 'A'-'Z', 'a'-'z', '0'-'9', '-', '_', '.', '{', '}'

A Progress ID failing to comply to those constrains should be immediately be rejected with a 403 (for tracked uploads) or 404 (requesting the progress) status code.

on a gentoo linux with apache 2.2.17 and passenger 3.0.7 :
with rails 3.0.7 and carrierwave 0.5.4
the json return always "uploading" and never send the "done" response.
the firsts replies are good :

{ "state" : "uploading", "received" : 14933299, "size" : 46876361, "speed" : 4977766, "started_at": 1306498419, "uuid" : "4b41a9394a672c78ba80ae699f738b66" }
{ "state" : "uploading", "received" : 42817011, "size" : 46876361, "speed" : 5352126, "started_at": 1306498419, "uuid" : "4b41a9394a672c78ba80ae699f738b66" }
{ "state" : "uploading", "received" : 46876361, "size" : 46876361, "speed" : 4687636, "started_at": 1306498419, "uuid" : "4b41a9394a672c78ba80ae699f738b66" }
{ "state" : "uploading", "received" : 46876361, "size" : 46876361, "speed" : 4687636, "started_at": 1306498419, "uuid" : "4b41a9394a672c78ba80ae699f738b66" }

but after that all queries return the same reply with "received" equal "size".
I get never the "done" response.
The query end when the page reload a new one and the file is correctly uploaded to the server.

Any idea about the problem ?

I have Wireshark output and the apache log with the module compiled with UP_DEBUG =1

Currently the response is in the form

new Object({ 'state' : 'uploading', 'received' : 883855, 'size' : 164705492, 'speed' : 294618  })

which is valid javascript, but not json. It would be ideal if the response were simply

{ 'state' : 'uploading', 'received' : 883855, 'size' : 164705492, 'speed' : 294618  }

so it could be handled as JSON and not requiring javascript evaluation. This would allow calls via .getJson in JQuery, etc.

Cheers,
Cypher

Hi,

I have a script querying for /progress every 1 second. The results from the queries follow (with timestamps added for clarity). I'm wondering why the state doesn't change for 5 seconds even though the received was equal to the size from the first request. Is this expected behavior, and it's just not useful to query the server that often?

Thanks,
Kristina

Thu, 14 Jul 2011 13:56:43 GMT
{ "state" : "uploading", "received" : 202341, "size" : 202341, "speed" : 202341, "started_at": 1310651802, "uuid" : "856076252401119245249600200441" }

Thu, 14 Jul 2011 13:56:44 GMT
{ "state" : "uploading", "received" : 202341, "size" : 202341, "speed" : 202341, "started_at": 1310651802, "uuid" : "856076252401119245249600200441" }

Thu, 14 Jul 2011 13:56:45 GMT
{ "state" : "uploading", "received" : 202341, "size" : 202341, "speed" : 202341, "started_at": 1310651802, "uuid" : "856076252401119245249600200441" }

Thu, 14 Jul 2011 13:56:46 GMT
{ "state" : "uploading", "received" : 202341, "size" : 202341, "speed" : 202341, "started_at": 1310651802, "uuid" : "856076252401119245249600200441" }

Thu, 14 Jul 2011 13:56:47 GMT
{ "state" : "uploading", "received" : 202341, "size" : 202341, "speed" : 202341, "started_at": 1310651802, "uuid" : "856076252401119245249600200441" }

Thu, 14 Jul 2011 13:56:48 GMT
{ "state" : "done", "size" : 202341, "speed" : 33723, "started_at": 1310651802, "uuid" : "856076252401119245249600200441" }

Hi

i cannot get it compiled using the command

sudo apxs -c -i -Wc,-arch -Wc,ppc7400 -Wl,-arch -Wl,ppc7400 -Wc,-arch -Wc,ppc64 -Wl,-arch -Wl,ppc64 -Wc,-arch -Wc,x86_64 -Wl,-arch -Wl,x86_64 -Wc,-arch -Wc,i386 -Wl,-arch -Wl,i386 mod_upload_progress.c

I am getting this output, no idea what it could mean:

/usr/share/apr-1/build-1/libtool --silent --mode=compile gcc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -I/usr/local/include -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -arch ppc7400 -arch ppc64 -arch x86_64 -arch i386 -c -o mod_upload_progress.lo mod_upload_progress.c && touch mod_upload_progress.slo
llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory
llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory
mod_upload_progress.c: In function ‘upload_progress_handle_request’:
mod_upload_progress.c:199: warning: format ‘%ld’ expects type ‘long int *’, but argument 3 has type ‘apr_off_t *’
mod_upload_progress.c:199: warning: format ‘%ld’ expects type ‘long int *’, but argument 3 has type ‘apr_off_t *’
mod_upload_progress.c: In function ‘reportuploads_handler’:
mod_upload_progress.c:711: warning: format ‘%ld’ expects type ‘long int’, but argument 3 has type ‘apr_off_t’
mod_upload_progress.c:711: warning: format ‘%ld’ expects type ‘long int’, but argument 4 has type ‘apr_off_t’
mod_upload_progress.c:726: warning: format ‘%ld’ expects type ‘long int’, but argument 3 has type ‘apr_off_t’
mod_upload_progress.c:726: warning: format ‘%ld’ expects type ‘long int’, but argument 4 has type ‘apr_off_t’
mod_upload_progress.c:726: warning: format ‘%ld’ expects type ‘long int’, but argument 5 has type ‘apr_off_t’
lipo: can't figure out the architecture type of: /var/tmp//cctKkmjS.out
apxs:Error: Command failed with rc=65536

Anybody knows the problem?

Thanks!

First of all, great module. Does exactly what I want!

I compiled the module from the master branch. I've got it set up in Rails using the jquery.uploadProgress.js script and after a fair amount of tinkering, I finally got it working. It now works perfectly in development. Here's my dev setup:

OSX 10.6
Apache 2.2.15
Passenger 3.0.2

In production, however, something's not right. When I upload a large file (15+ MB), it works perfectly - the 'uploading' status returns immediately. When I upload smaller files (~5MB), it never gets past 'starting'. As the upload finishes, I sometimes see one result showing 'uploading' or 'done'. My production setup is:

Ubuntu 9.04
Apache 2.2.11
Passenger 3.0.2

Any ideas why this might be happening?

Thanks again for a great module!

Hi all,
I've set up a vhost on my local machine called development.local (there's an entry for it in /etc/hosts)

Going to http://development.local and uploading a file (submitting to an iframe) works well. However, trying to access upload data from /progress?X-Upload-ID=test doesn't work properly.
If I start an upload of a 20Mb file, it takes about 4 seconds to complete. During that time, hitting the progress url will wait until the upload has finished before returning any data.

My rails app view looks like:
<% title "New Submission" %>
<% content_for :scripts do %>
<%= javascript_include_tag 'upload' %>
<% end %>

<% form_for :upload, :url=>"/upload?X-Progress-ID=test", :html=>{:multipart=>true} do |form| %>
<%= hidden_field_tag 'X-Progress-ID', 'test' %>
<%= form.file_field :file %>
<%= form.submit 'Upload', :class=>'submit' %>
<% end %>
<%= content_tag :iframe, :name=>"upload_frame", :style=>"border: 1px solid red; height: 200px; width: 800px" %>

the javascript, which changes the form target attribute and logs (using firebug)
Event.observe(window, 'load', function(){
$("upload_submit").observe('click', function(){
$$("body").first().insert({bottom:"<iframe name='upload_frame' style='border: 1px solid red; height: 100px; width: 800px;></iframe>"});
$(this).up('form').writeAttribute("target", "upload_frame");
$(this).up('form').submit();
log("STARTING");
new PeriodicalExecuter(function(pe){
new Ajax.Request("http://inspired.local/progress?X-Progress-ID=test", {method:'get', onSuccess: function(t){log(t.responseText)}, afterFinish: function(){log("DONE")}});
}, 1);
});
});

any ideas where i may be going wrong, or where to look for possible bugs?

When uploading a file with 0 bytes size, the request is not passed to my application (rails), and progress is blocked on : { "state" : "starting" }
There is no error log in apache.

I will try to submit a patch if I find the time.

We installed latest version of module, Apache 2.2.17. progress bar appears only for couple of seconds when upload reaches %100. Cannot figure out why it happens.

Thank You

When reviewing your source I found the following place which I don't see any good reason for:

static apr_status_t upload_progress_cache_module_kill(void *data)
{
    ServerConfig *st = (ServerConfig*)data;

    upload_progress_destroy_cache(st);

#if APR_HAS_SHARED_MEMORY
    //FIXME!: Second block of code gets never executed!
    if (st->cache_rmm != NULL) {
        apr_rmm_destroy (st->cache_rmm);
        st->cache_rmm = NULL;
    }
    if (st->cache_shm != NULL) {
        apr_status_t result = apr_shm_destroy(st->cache_shm);
        st->cache_shm = NULL;
        return result;
    }
#endif
    return APR_SUCCESS;
}

As you can see there's an assignment in the first if block that when executed falsifies the condition of the second thus making the second block dead code. Furthermore both blocks are (except for the first one not returning the result of the apr_destroy operation) identical AFAIC.

My idea would be removing the first block or merging it with the second. Any arguments against doing so?

start uploading file, press 'stop' button in the browser before upload is finished - upload progress would return 'success' status message, though the file was not actually uploaded.

Dear Drogus, dear All,

thanks for the great module. It is currently used in rails 2.3.8 (OpenSUSE 11.3 x64, Apache 2.2.15 + mod_passenger, Ruby 1.8.7 ) based system where external people can upload huge zip compressed image files between 25 MB and 700 MB size to the server where our web app is hosted. Our web app has a default timout of 10 minutes. This means, our users have to authenticate and login. After 10 minutes of inactivity the user would have to reauthenticate. It there was user activity within the 10 minutes timeout period, the time out would be reset. This is implemented using the ruby authlogic solution (https://github.com/binarylogic/authlogic/).

The problem is when customers have a relatively slow internet connection. If the file upload does not finish within 10 minutes due to limited upload bandwidth, we observe this behaviour:

1. Progress bar completes until 100%. This may take much more time than the above mentioned time out value of 10 minutes. It actually seems that the upload completes.

2. After the progress bar reaches 100% the user is redirected to the login page to reauthenticate, and postprocessing of the upload has not occured.

With simple HTTP based uploads (of course without the progress bar) the in 2) mentioned behaviour does not occur. It seems that the HTTP based upload method resets the time out counter while uploading via the apache-upload-progress-module does not reset the timeout counter.

I would like to know whether someone has similar experiences and whether there is a fix for that.

Thanks in advance,
pcdoc80