Nginx возвращает ошибку 408 при загрузке файла XHR2 во время загрузки в середине
Мой клиент пытается загрузить файл на наш удаленный веб-сервер nginx через форму POST, используя данные формы XHR2 (и междоменный запрос с CORS). Во время промежуточной загрузки веб-сервер возвращает 408, и обработчик ошибок ajax в результате останавливает обработку. Файлы находятся в диапазоне 20-120 МБ. Журналы доступа для некоторых файлов загружаются следующим образом (он пробовал на Chrome 31 и IE11):
[24/Dec/2013:16:44:18 -0500] "OPTIONS / HTTP/1.1" 200 0 "http://www.example.com/files/upload" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36"
[24/Dec/2013:16:47:50 -0500] "POST / HTTP/1.1" 408 0 "http://www.example.com/files/upload" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36"
...
[27/Dec/2013:01:23:51 -0500] "OPTIONS / HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko"
[27/Dec/2013:01:33:11 -0500] "POST / HTTP/1.1" 408 0 "http://www.example.com/files/upload" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko"
Иногда файлы будут загружаться для него отлично с Chrome вместо IE, а иногда наоборот, но в большинстве случаев ни один браузер не будет работать для него.
Я читал вики nginx, и единственные две настройки, которые связаны с ошибками 408: client_body_timeout
а также client_header_timeout
, Мне трудно понять значение этих двух директив. Я увеличил оба до 180 секунд, но проблема сохраняется. Я спросил его, было ли у него медленное соединение, и он сказал, что у него скорость 2,5 Мбит / с, что должно быть достаточно быстрым, чтобы полностью получить заголовок запроса (но опять же, мы не уверены, что означают эти 2 директивы согласно вики, например, что такое "readstep"). Ранее мы успешно получали 1 ГБ на наш сервер от других клиентов, что обычно занимает около часа.
Для проблемных файлов, которые мы в конечном итоге успешно получили от наших клиентов, мы попытались загрузить один и тот же файл в различные браузеры, и он работал отлично.
Я читал, что использование SSL может привести к тайм-ауту, но на сервере не включена поддержка SSL, и мы используем только http.
Наш nginx.conf:
user www-data;
worker_processes auto;
pid /run/nginx.pid;
events {
worker_connections 5000;
# multi_accept on;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay off;
keepalive_timeout 25;
# Increase client/head body_timeout to prevent 408's for slow Internet connections??
client_header_timeout 180;
client_body_timeout 180;
types_hash_max_size 2048;
server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
##
# Gzip Settings
##
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types
application/atom+xml
text/javascript
application/javascript
application/json
application/rss+xml
application/vnd.ms-fontobject
application/x-font-ttf
application/x-web-app-manifest+json
application/xhtml+xml
application/xml
font/opentype
image/svg+xml
image/x-icon
text/css
text/plain
text/x-component;
# Increase FastCGI buffers
fastcgi_read_timeout 1500;
fastcgi_buffers 8 16K;
fastcgi_buffer_size 32K;
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
Наш сервер загрузки конфигурации:
server {
listen 80;
server_name upload.example.com;
root /var/www/releases/latest/_UPLOAD/public;
# remove trailing slash, that throws ZF router
if (!-d $request_filename) {
rewrite ^/(.*)/$ /$1 permanent;
}
# 1.2G upload limit + 10M for post data (which is extremely liberal)
client_max_body_size 1210M;
client_body_buffer_size 4M;
proxy_max_temp_file_size 0;
location = /favicon.ico {
access_log off;
log_not_found off;
}
location = /apple-touch-icon.png {
access_log off;
log_not_found off;
}
location / {
# This is for AJAX file uploads... need to set CORS headers
if ($request_method = OPTIONS ) {
add_header Access-Control-Allow-Origin '$scheme://www.example.com';
add_header Access-Control-Allow-Methods 'POST, OPTIONS';
add_header Access-Control-Allow-Headers 'X-Requested-With, Content-Type, Content-Range, Content-Disposition';
return 200;
}
try_files $uri $uri/ /index.php?$args;
index index.php index.html index.htm;
}
location ~ \.php$ {
try_files $uri $uri/ /index.php?$args;
index index.php index.html index.htm;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/releases/latest/_UPLOAD/public$fastcgi_script_name;
fastcgi_param APPLICATION_ENV production;
fastcgi_param PATH /usr/bin:/bin:/usr/sbin:/sbin;
fastcgi_intercept_errors on;
include fastcgi_params;
}
error_page 403 =404 /404.html;
error_page 404 /404.html;
location = /404.html {
root /var/www/releases/latest/_UPLOAD/public;
internal;
}
error_page 500 502 503 504 = /50x.html;
location = /50x.html {
root /var/www/releases/latest/_UPLOAD/public;
internal;
}
}
Есть ли в конфигурации что-то, что может помешать успешной загрузке и вызвать эти надоедливые ошибки 408? В журналах ошибок об этой проблеме ничего не упоминается.
ПРИМЕЧАНИЕ: мы использовали только reload
когда мы вносим изменения в конфигурацию nginx. Мы пытаемся избежать restart
но если это требуется для того, чтобы изменения в конфигурации вступили в силу, мы это сделаем.