Today, I was surprised to find a saying on the Internet. As we all know, If I upload a file to the nginx proxy server, nginx will save the file and then send it back. In this process, nginx will create a temporary file. Since it is a temporary file, it is clear that there will be a file in the file system. Therefore, nginx will be able to send a saying on the Internet that was accidentally discovered today. As we all know, nginx will save the file when uploading a file to the nginx proxy server, and then send it to the backend. In this process, nginx will create a temporary file. Since it is a temporary file, it is clear that there will be a file in the file system. Therefore, nginx can send a temporary file name later, instead of a whole file! Then the backend can directly read the file name.
The file name is provided by a variable in nginx, that is, $ request_body _
File, In the nginx
PhpFastcgi_params:
Fastcgi_param REQUEST_BODY_FILE $ request_body_file;
Therefore, in the nginx proxy configuration, you can also write:
Proxy _
Set_ Header request_body_file $ request_body_file;
Although nginx can upload the file name of this temporary file to the backend, it still needs to meet some conditions to use this optimization:
1) the backend must be on the same machine as the proxy. This does not need to be explained.
2) the backend must support this optimization. In most application servers, the upload function can be disabled, and only the request_header can be read. In this case, this variable is available, in fact, the application server software that does not support uploading can easily add the file upload function.
----------------
I tested it today and found several problems:
1) for small files, such as common text and small images, nginx stores them in the memory and does not write the files. In this case, the backend may not get the request_body_file header, or the obtained file does not exist. Through Configuration:
Client_body_in_file_only on;
So that nginx can write all uploaded files to the file, so that the test will be smooth.
2) although you can get the file request_body_file, this file cannot be used directly. It contains a little bit of format, similar:
----------------------------- 7d9abd10206
Content-Disposition: fo
Rm-Data; name = img1; filename = D: Pic11.jpg
Content-Type: image/pjpeg
[Image File Content] Save ......
----------------------------- 7d9abd10206
Therefore, after obtaining this file, you must perform some processing on it to become a real file. Although the processing principle is very simple, it still seems complicated.
The value 7d9abd10206 can be obtained in the Content-Type of the request header. In this example, the Content-Type is:
Content-Type: multipart/form-data; boundary = --------------------------- 7d91092110206
3) If two files are uploaded at the same time, the saved file becomes:
----------------------------- 7d9abd10206
Content-Disposition: form-data; name = img1; filename = D: Pic11.jpg
Content-Type: image/pjpeg
[Image File Content 1] Save ......
----------------------------- 7d9abd10206
Content-Disposition: form-data; name = img2; filename = D: Pic12.jpg
Content-Type: image/pjpeg
[Image File Content 2] saving ......
----------------------------- 7d9abd10206
This is obviously even more difficult. To save system IO and pursue high efficiency, you need to write a module for processing.
4) I tried to use:
Proxy_pass_request_body off;
To prevent nginx from sending request_body content to the backend, but this actually triggers the nginx bug, resulting in the request timeout cannot be completed. The nginx version I tested is 0.7.59.
