Un cliente mío está intentando cargar un archivo en nuestro servidor web nginx remoto a través de un formulario POST utilizando datos del formulario XHR2 (y una solicitud entre dominios con CORS). Durante la carga media, el servidor web devuelve un 408 y, como resultado, el controlador de errores ajax detiene el procesamiento. Los archivos están en el rango de 20 a 120 MB. Los registros de acceso para algunas de las cargas de archivos son los siguientes (lo probó en Chrome 31 e 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"
A veces, los archivos se cargarán perfectamente bien con Chrome en lugar de IE, y a veces viceversa, pero la mayoría de las veces ninguno de los navegadores funcionará para él.
He estado leyendo la wiki de nginx y las únicas dos configuraciones que se correlacionan con errores 408 son client_body_timeouty client_header_timeout. Me cuesta entender el significado de estas dos directivas. Aumenté ambos a 180 segundos pero el problema persiste. Le pregunté si tenía una conexión lenta y dijo que tiene 2,5 Mbps, lo que debería ser lo suficientemente rápido para recibir completamente el encabezado de la solicitud (pero nuevamente, no estamos seguros de qué significan estas 2 directivas según elwiki, como qué es un "paso de lectura"). Ya hemos recibido con éxito cargas de 1 GB en nuestro servidor de otros clientes, que normalmente tardan alrededor de una hora en finalizar.
Para los archivos problemáticos que finalmente recibimos exitosamente de nuestro cliente, intentamos cargar el mismo archivo en varios navegadores y funcionó perfectamente.
He leído que el uso de SSL podría causar tiempos de espera, pero el servidor no tiene SSL habilitado y solo estamos usando http.
Nuestro 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/*;
}
Nuestra configuración del servidor de carga:
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;
}
}
¿Hay algo en la configuración que pueda impedir las cargas exitosas y causar estos molestos errores 408? No se menciona nada en los registros de errores sobre este problema.
NOTA: Solo lo hemos usado reloadcuando realizamos cambios en la configuración de nginx. Estamos tratando de evitar un problema, restartpero si es necesario para que nuestros cambios de configuración surtan pleno efecto, lo haremos.