Nginx UploadProgress Module
The module for nginx, with which you can simply monitor the progress of downloading files to the server. Earlier there were similar solutions, through modules to php, ruby, through third-party scripts, flash objects and so on. The author proposes a universal solution at the web server level. Detailed information and instructions you can find on wiki.codemongers.com (by the way, one of the best projects dedicated to nginx `y). Here I wanted to draw attention to another.
Used the module in conjunction with the nginx upload module , works with a bang. However, the files that I upload are quite large (I support file sharing), I tried to stuff the size of the files being processed into the upload_progress directive - 1g , while reloading nginx, I received a warning, supposedly incomprehensible size you put. Strange, because in client_max_body_size I have 1g and feels fine. I looked at the source code of nginx and the module, it turned out that the module processes the upload_progress directive with the ngx_parse_size function, while nginx itself processes the same client_max_body_size with the neighboring function ngx_parse_offset , the functions are absolutely identical (in my opinion), except that the first one does not understand the dimension āgā. the second one understands =) In order for the module to properly handle the dimension in the upload_progress directive, it is necessary in the source of the module (ngx_http_uploadprogress_module.c) in line 1151 to correct ngx_parse_size to ngx_parse_offset .
In general, this is not critical, because The directive normally processes the value of 1024m , but somehow such an entry looks ridiculous =)))
In general, I really liked the module, a very convenient solution that does not depend on the back-end.
update : Attention, made a stupid mistake. Shame on you The upload_progress directive does not set the maximum size of uploaded files for the specified zone, as I thought, but the amount of RAM allocated for calculating one download to this zone. The value for this directive is 1.2m, maximum 10-20m. By asking 1g you will spend a gigabyte of RAM for each download. It's a shame, do not repeat the mistake.
ps Nevertheless the bug is found, the author said, he promised to fix it.
Used the module in conjunction with the nginx upload module , works with a bang. However, the files that I upload are quite large (I support file sharing), I tried to stuff the size of the files being processed into the upload_progress directive - 1g , while reloading nginx, I received a warning, supposedly incomprehensible size you put. Strange, because in client_max_body_size I have 1g and feels fine. I looked at the source code of nginx and the module, it turned out that the module processes the upload_progress directive with the ngx_parse_size function, while nginx itself processes the same client_max_body_size with the neighboring function ngx_parse_offset , the functions are absolutely identical (in my opinion), except that the first one does not understand the dimension āgā. the second one understands =) In order for the module to properly handle the dimension in the upload_progress directive, it is necessary in the source of the module (ngx_http_uploadprogress_module.c) in line 1151 to correct ngx_parse_size to ngx_parse_offset .
In general, this is not critical, because The directive normally processes the value of 1024m , but somehow such an entry looks ridiculous =)))
In general, I really liked the module, a very convenient solution that does not depend on the back-end.
update : Attention, made a stupid mistake. Shame on you The upload_progress directive does not set the maximum size of uploaded files for the specified zone, as I thought, but the amount of RAM allocated for calculating one download to this zone. The value for this directive is 1.2m, maximum 10-20m. By asking 1g you will spend a gigabyte of RAM for each download. It's a shame, do not repeat the mistake.
ps Nevertheless the bug is found, the author said, he promised to fix it.
')
Source: https://habr.com/ru/post/41502/
All Articles