这几天一位前端同事在处理上传请求时候nginx返回500错误,没有额外错误信息,后端也没有接收到请求,看他本地nginx日志错误:
[crit] 28700#21636: *1389 CreateFile() "\nginx-clean/temp/client_body_temp/0000000010" failed (5: Access is denied)
把**/temp/client_body_temp这个文件夹权限改成执行Nginx的用户群组就能够解决
nginx有几个上传相关参数说明:
client_max_body_size
client_max_body_size 默认 1M,表示 客户端请求服务器最大容许大小,在“Content-Length”请求头中指定。若是请求的正文数据大于client_max_body_size,HTTP协议会报错 413 Request Entity Too Large。
client_body_buffer_size
Nginx分配给请求数据的Buffer大小,若是请求的数据小于client_body_buffer_size直接将数据先在内存中存储。若是请求的值大于client_body_buffer_size小于client_max_body_size,就会将数据先存储到临时文件中
client_body_temp_path
指定临时存储路径,默认该路径值是/tmp/client_body_temp
配置的client_body_temp地址,必定让执行的Nginx的用户组有读写权限。不然,当传输的数据大于client_body_buffer_size,写进临时文件失败会报错
语法:client_body_temp_path dir-path[level1[level2[level3]]] 如果包体的大小大于client_body_buffer_size,则会以一个递增的整数命名并存放到client_body_temp_path指定的目录中。后面跟着的level1、level2、level3,是为了防止一个目录下的文件数量太多,从而导致性能下降,
因此使用了level参数,这样可以按照临时
client_body_in_file_only on|clean|off;
当值为非off时, 用户请求中的HTTP包体一律存储到磁盘文件中, 即使只有0字节也会存储为文件。
当请求结束时,如果配置为on,则这个文件不会被删除(该配置一般用于调试、定位问题),但如果配置为clean,则会删除该文件。
总结:
传输的数据大于 client_max_body_size,必定是传不成功的,HTTP协议会报错 413 Request Entity Too Large
小于 client_body_buffer_size直接在内存中高效存储。
若是大于 client_body_buffer_size 小于 client_max_body_size 会存储临时文件,临时文件必定要有权限。
若是追求效率,就设置 client_max_body_size 和 client_body_buffer_size 相同的值,这样就不会存储临时文件,直接存储在内存了。