Anatoly

@debjitk my advice is do not write custom authentication mechanism, but using built-in functionality http://nginx.org/en/docs/http/ngx_http_auth_request_module.html

it helps you to do backend request (with following database rules detection) easily.

@hamzakc, no, RFC 2388 (multipart/form-data) doesn't supported by Nginx clientbodyinfileonly

@digitaloast the reference: https://github.com/vkholodkov/nginx-upload-module/issues/41

@vaggos2002 please look at RFC 1867. You can upload files one of either way: multipart form data or as a binary.

@ronnyf what is the user and group you have in Nginx configuration file? I've checked the files created with the user you specified. If that does not help, please take a look at http://en.wikipedia.org/wiki/Setuid#setgid_on_directories

@mandrei99 once you are start using non-supported plugins, it stops you from being on the latest stable Nginx version. New release is out, you are waiting for new patch again.
For example SPDY/2 support will be discontinuing soon, so Nginx 1.5.10 is a must.

We decided do not do that. Just using built-in functionality and develop a service on top of it. Core functionality is enough for our tasks.

@mandrei99 this plugin author's attitude is pretty clear https://github.com/vkholodkov/nginx-upload-module/issues/41

It's a bit dangerous to rely on patches that can break and make core functionality of Nginx and upload-module unstable

@pointblank, I don't think it's possible because Nginx has its own internal naming conventions for body request content

@2naive, в рассылке были вопросы по этому поводу, но, насколько я в курсе изменений, этот модуль не трогали (лишь добавили auth_request по просьбам), поэтому на имя файла влиять пока нельзя.

@kliuchnikau in case you have separate deployment user web-server may need to get the access to app tmp directory at least. So the approach is to run webserver under deployer user, it should be ok if you can control the application itself.

through custom headers that Nginx preserve, they come with original request

@meson10 change the way you upload the file, get rid of multipart/form-data

@xfrf how do you upload a file?

@goace, the file stores to the local file system that's right. Once it has been uploaded the backend got synchronous callback (with X-FILE header and empty BODY) to the any URL you specified (http://backend/file in my case)

@dawncold We do use extra headers with POST that pass through Nginx proxy and comes to back-end unmodified. So try to use X-NAME headers from initial requests and you will catch it up on backend.

@dawncold you are able to send desirable file name in extra header and reuse it on back-end afterwards

@eppo yes, this is the callback, it fires only if file is uploaded and saved on disk successfully.

@eppo back-end receives a request to URL http://backend/file with empty body(!) and the file name is header X-FILE. The storage location is declared by clientbodytemp_path

@cbess this solution is not for everybody, but for specific requirements. Please re-read the post again. Sure, proxy doubles the traffic and use CPU, in terms of scalability it solves by using array of Nginx servers.

@cbess CloudFrount CDN is not feature of S3! CloudFront can use S3 just as origin.
For some reason CDN is not an option for certain business purposes, such data privacy, specific geo-location (if should not be replicated to another regions).

@niko,

1) it's not right, Nginx only pass the filename instead of full file body to backend. So the backend should not parse and cut the Content-Disposition headers.

2) back-end is not blocked until the file is uploaded by Nginx in any case

3) Nginx and back-end should have the same filesystem, it's right.

@dawncold because clientbodyinfileonly doesn't support RFC 2388

thanks for nice post, let me ask you to update SQL with the following style please:

   SELECT * FROM users AS u
LEFT JOIN user_profiles AS p 
       ON p.user_id = u.id 
    WHERE 1
      AND u.block = 1 
      AND (p.profile_key = 'moderator' AND p.profile_value = 1)
 ORDER BY u.name

crontab -e

0 1 * * * /bin/sync; echo 3 > /proc/sys/vm/drop_caches;

measure things before you say what exactly optimised and how much it is

if you use mysqldump, do it with --quick at least

just run it before production branches merge

$ ack 'console.log' -r

Completely disable is not a solution, and you can find a fix here: https://groups.google.com/forum/#!topic/rubyonrails-security/61bkgvnSGTQ/discussion

I don't think it's a hack, it's simple Unix way, the same as Rbenv. One problem = one solution.

If you don't want Rbenv magic, just use
PATH = /usr/local/rbenv/shims:/usr/local/rbenv/bin:$PATH

And yes, I don't like RVM for some reasons.

WHY U NO USE Bundler binstubs?

what is about default hooks for html5 data attributes to handle AJAX behavior? it ships with jquery-rails already

bundle exec --binstubs
export PATH=./bin:$PATH